קישור HTTPS שעובד הוא רק תחילת החיים של אתר סטטי. אחרי הפרסום צריך להבין אם מישהו פתח את הקישור, מאיפה הגיעו הביקורים, אילו עמודים באמת נצפו, באילו מכשירים השתמשו, והאם האתר מבזבז רוחב פס בגלל תמונות או קבצים כבדים מדי.
בשלב הראשון לא תמיד צריך מערכת ניתוח מלאה. צריך שכבה קלה של סטטיסטיקות, כזו שעוזרת להחליט מה לתקן עכשיו ומה יכול לחכות.
התחילו מהשאלה, לא מהגרף
מספרים בלי הקשר גורמים לאנשים להסתכל על dashboard במקום לשפר את האתר.
אתר portfolio לא נמדד כמו דף נחיתה. דוקומנטציה לא נמדדת כמו קורות חיים אונליין. פרויקט לימודים צריך בעיקר להיפתח אצל המרצה או הבודק. אתר שנוצר עם AI צריך להיבדק מול פלט אמיתי: האם העמודים והקישורים שה-AI יצר באמת עובדים אחרי העלאה?
| סוג אתר | שאלה שימושית אחרי הפרסום |
|---|---|
| תיק עבודות אונליין | האם מבקרים נכנסים לעמודי פרויקטים או נשארים בדף הבית? |
| קורות חיים אונליין | האם הקישור נפתח אחרי שנשלח למגייס או לטופס מועמדות? |
| דף נחיתה | האם מקורות התנועה תואמים את הקמפיין? |
| אתר תיעוד | אילו עמודים משמשים נקודות כניסה? |
| פרויקט לימודים | האם הקישור עובד מחוץ למחשב שלכם? |
| אתר שנוצר עם AI | האם המבקרים מגיעים לעמוד הנכון אחרי תיקון מבנה הקבצים? |
כשיודעים מה רוצים לברר, קל יותר לא להתרגש מכל שינוי קטן בגרף.
ביקורים ומבקרים אינם אותו דבר
ביקורים מספרים כמה פעמים עמודים נפתחו. מבקרים מנסים להעריך כמה אנשים או סשנים נפרדים היו, בהתאם לאופן המדידה של הכלי.
ההבדל הזה חשוב. הרבה ביקורים עם מעט מבקרים יכולים להיות צוות פנימי שמרענן את האתר בזמן בדיקה. הרבה מבקרים בלי מעבר לעמודים נוספים יכולים להצביע על עמוד פתיחה שלא עונה לציפייה מהקישור.
| מה רואים | פירוש אפשרי | פעולה הגיונית |
|---|---|---|
| קפיצה ביום הפרסום | בדיקות פנימיות ורענונים חוזרים | לא להסיק מוקדם מדי. |
| מעט מבקרים ממקור ברור | הקישור חולק בערוץ אחד בלבד | לחכות להפצה רחבה יותר. |
| עלייה אחרי חיבור דומיין | הכתובת נראית אמינה יותר או קלה יותר לשיתוף | לבדוק גם עמודים מובילים. |
| הרבה כניסות לעמוד אחד בלבד | המסר, מהירות הטעינה או הקריאה לפעולה דורשים בדיקה | לפתוח את העמוד בטלפון ולבדוק אותו מחדש. |
Cloudflare Web Analytics, Plausible ו-Matomo משתמשים במונחים מעט שונים עבור page views, visits, visitors, referrers ומכשירים. העיקרון נשאר אותו דבר: לא נותנים למדד יחיד לספר את כל הסיפור.
מקורות תנועה מראים אם הקישור הגיע למקום הנכון
אתרים סטטיים מתפזרים לעיתים קרובות דרך ערוצים לא אחידים: LinkedIn, WhatsApp, Telegram, דוא״ל, QR, מצגת, PDF, פרופיל אישי או מערכת לימודים. מקורות תנועה עוזרים להבין מה באמת הביא אנשים לאתר.
צריך לזכור שחלק מהאפליקציות והדפדפנים לא מעבירים referrer מלא. לכן תנועה שמופיעה כ-direct לא בהכרח אומרת שמישהו הקליד את הכתובת ידנית. לפעמים המקור פשוט לא נשלח.
כשמדובר בקמפיין קטן, כדאי להשתמש ב-UTM. אפשר ליצור קישורים מסודרים עם UTM builder:
| ערוץ | דוגמת סימון |
|---|---|
utm_source=linkedin&utm_medium=social | |
| דוא״ל | utm_source=newsletter&utm_medium=email |
| QR באירוע | utm_source=event&utm_medium=qr |
| הצעת מחיר או PDF | utm_source=proposal&utm_medium=pdf |
| קישור לקורות חיים | utm_source=resume&utm_medium=document |
UTM מתאים לכניסות מבחוץ. אל תוסיפו אותו לכל קישור פנימי באתר, אחרת הנתונים יתלכלכו במקום להתבהר.
מכשירים ודפדפנים אומרים איפה להתחיל QA
הרבה אתרים סטטיים נראים טוב על הלפטופ של המפתח ונשברים דווקא בטלפון.
נתוני מכשירים ודפדפנים עוזרים לקבוע סדר עדיפויות. אם רוב המבקרים במובייל, תמונה כבדה, טבלה רחבה, כפתור קטן או כתובת ארוכה שלא נשברת יכולים להפוך לבעיה מרכזית. אם דפדפן מסוים מופיע לא מעט, פתחו את האתר בו אחרי כל עדכון משמעותי.
בדיקה קצרה:
- לפתוח את דף הבית ואת העמודים המובילים בטלפון.
- לבדוק תפריטים, כפתורים, טפסים, תמונות וקישורי הורדה.
- לחפש טקסטים שנשפכים מחוץ למסך.
- לבדוק את העמודים שאנשים באמת פותחים, לא רק את העמודים שנוח לכם לבדוק.
- אחרי העלאת גרסה חדשה, לראות אם דפדפן או מכשיר מסוים מתנהג אחרת.
סטטיסטיקות לא מחליפות בדיקות. הן אומרות איפה כדאי להתחיל.
עמודים מובילים חושפים הנחות שגויות
קל להניח שכולם מתחילים מדף הבית. בפועל, אנשים נכנסים לפעמים ישירות לעמוד פרויקט, דף תמחור, מדריך, PDF או עמוד ישן שקיבל קישור ממקום אחר.
זה נפוץ באתרים סטטיים כי קל לשתף URL ישיר.
כשבודקים עמודים מובילים, שאלו:
- האם העמוד מובן למי שנכנס אליו בלי הקשר?
- האם הכותרת והתיאור מדויקים?
- האם הוא עובד במובייל?
- האם יש פעולה הבאה ברורה?
- האם עמוד ישן עדיין מקבל ביקורים אחרי שינוי מבנה האתר?
אם עמוד ישן עדיין מקבל תנועה, אל תמחקו אותו בלי מחשבה. צרו חלופה, עדכנו קישורים, או הפנו אנשים לתוכן החדש. לפני שינוי גדול, כדאי לשמור דרך ברורה ל-שחזור גרסה קודמת.
רוחב פס הוא סימן מוקדם לבעיית חוויה
אתר סטטי לא מריץ backend בכל בקשה, אבל הקבצים עצמם עדיין יכולים להיות כבדים.
תמונה גדולה מדי, PDF שנטען שוב ושוב, פונט כבד או bundle מיותר יכולים להאט אתר ולהגדיל שימוש ברוחב פס. לפעמים זה לא מורגש בזמן בדיקה פנימית, ורק אחרי שהקישור מופץ מתחילים לראות את זה.
אם רוחב הפס עולה מהר יותר מהביקורים, בדקו:
| סיבה אפשרית | איך לבדוק |
|---|---|
| תמונות גדולות מדי | לבדוק גדלי קבצים בתיקיית ה-build או ב-DevTools. |
| PDF שנפתח הרבה | לבדוק עמודים וקבצים מבוקשים. |
| יותר מדי פונטים | לצמצם משפחות ומשקלים שלא באמת בשימוש. |
| JavaScript כבד | לוודא שעמוד סטטי לא גורר ספריות מיותרות. |
| שימוש חיצוני בקבצים | לבדוק מקורות תנועה ודפוסי בקשות חריגים אם זמינים. |
באתרי portfolio ודפי נחיתה, דחיסת תמונות וניקוי נכסים לא בשימוש הם בדרך כלל התיקונים המהירים ביותר.
מתי צריך כלי ניתוח עמוק יותר?
סטטיסטיקות בסיסיות עונות על השאלות הראשונות: האם הקישור נפתח, מאיפה הגיעו הביקורים, אילו עמודים נצפו, באילו מכשירים השתמשו, והאם רוחב הפס סביר.
כלים כמו Google Analytics, Plausible או Matomo נכנסים כשצריך מעקב אירועים, funnels, ייחוס קמפיינים מפורט, או דוחות שמתחברים למערכות שיווק ומכירות.
סדר בריא יותר:
- מפרסמים את האתר.
- קוראים סטטיסטיקות בסיסיות.
- מתקנים עמודים, מכשירים וקבצים בעייתיים.
- מוסיפים כלי ניתוח עמוק רק כשיש שאלה שהשכבה הבסיסית לא עונה עליה.
לא חייבים להוסיף עוד script רק כדי שהאתר ירגיש רציני. כל script חיצוני מוסיף שיקולי ביצועים, פרטיות ותחזוקה.
פרטיות, עוגיות ו-scripts חיצוניים
מדידה היא גם החלטת פרטיות.
אם מוסיפים כלי חיצוני, צריך לבדוק מה הוא אוסף, האם הוא משתמש בעוגיות, האם יש צד שלישי שמקבל נתונים, ואיך זה מוצג במדיניות הפרטיות או במדיניות העוגיות. אל תעתיקו טקסט משפטי מאתר אחר ואל תבטיחו תאימות שאין לה בסיס.
לאתרים קטנים, סטטיסטיקות מובנות יכולות להיות שכבה ראשונה קלה יותר. כשהצורך גדל, בוחרים כלי מתאים ומעדכנים את ההסברים למשתמשים בהתאם.
קצב בדיקה לשבוע הראשון
השבוע הראשון אחרי הפרסום נותן מספיק מידע אם בודקים אותו בזמן הנכון.
| זמן | מה לבדוק |
|---|---|
| יום הפרסום | HTTPS, דף הבית, נכסים, תמונות וקישורים מרכזיים. |
| אחרי השיתוף הראשון | האם מקורות התנועה תואמים לערוצים שבהם שיתפתם? |
| היום השני | עמודים מובילים, מכשירים ודפדפנים. |
| ימים 3-7 | רוחב פס, עמודים ישנים, מקורות חריגים ו-direct traffic. |
| אחרי עדכון גדול | להשוות עמודים ומקורות לפני ואחרי הגרסה החדשה. |
המטרה אינה לבהות בגרף. המטרה היא לדעת מה הפעולה הבאה.
איך DeployPages משתלב בתהליך
DeployPages משלב סטטיסטיקות כחלק מתהליך פרסום אתר סטטי, בלי לדרוש ממך לבנות מערך מדידה לפני הקישור הראשון.
התהליך יכול להיראות כך:
- מעלים תיקייה, ZIP, PDF או תוצר build סטטי.
- מקבלים קישור HTTPS ציבורי.
- משתפים עם לקוח, צוות, מגייס, כיתה או קמפיין.
- קוראים סטטיסטיקות: ביקורים, מקורות תנועה, עמודים, מדינות, מכשירים, דפדפנים ורוחב פס.
- מחברים דומיין מותאם אישית כשהפרויקט הופך רשמי.
- מוסיפים CLI deploys, הגנה בסיסמה או שחזור גרסה כשהעדכונים נעשים קבועים.
להרבה אתרים סטטיים זה הסדר הנכון: קודם קישור שעובד, אחר כך כלים עמוקים יותר.