לא כל אתר ישן צריך החלפה — אבל כל אתר צריך לעמוד בבדיקה
הסיבה הנכונה ל-redesign אינה שהאתר “נראה משנת 2018”. הסיבה היא שהאתר כבר לא עוזר לאנשים לבצע את הפעולה שלשמה הגיעו: להבין את ההצעה, לסמוך על העסק וליצור קשר.
לפני שמחליפים פלטפורמה או מתחילים לעצב מסכים חדשים, בדקו את שבעת הסימנים הבאים. אם כמה מהם מופיעים יחד, כדאי לבצע audit מסודר — לא להסתפק בשכבת צבע חדשה.
1. המבקר לא מבין בתוך כמה שניות מה העסק מציע
בדקו את עמוד הבית בלי הקשר: האם כותרת ראשית מסבירה למי אתם עוזרים ובמה? האם ברור מה הצעד הבא? אם התשובה תלויה בגלילה ארוכה או בקריאת תפריט, הבעיה היא בדרך כלל בהיררכיית המסר, לא בגודל הלוגו.
2. האתר נראה סביר במחשב, אבל נשבר בטלפון
לקוחות רבים פוגשים עסק דרך מסך קטן. בדקו תפריט, כפתורים, טפסים, תמונות, טקסט דו-לשוני וקריאות לפעולה במכשיר אמיתי — לא רק בתצוגת preview. אל תסתפקו ב“האתר רספונסיבי”; בדקו אם הוא שימושי.
3. המשתמשים מחכים, לוחצים — ושום דבר לא קורה
מדדו את החוויה בפועל. Google מגדירה את Core Web Vitals דרך שלושה ממדים: טעינה (LCP), תגובתיות (INP) ויציבות ויזואלית (CLS), עם יעדי “טוב” של LCP עד 2.5 שניות, INP מתחת ל-200 מילישניות ו-CLS מתחת ל-0.1. אלה אינם תחליף למחקר משתמשים, אבל הם סימן טכני חשוב לבדיקה.
התחילו בנתוני משתמשים אמיתיים ב-דוח Core Web Vitals של Google, ולא רק בציון מעבדה בודד.
4. תוכן חשוב קיים — אבל אי אפשר למצוא אותו
אם שירות, מחירון, שאלות נפוצות או דרך יצירת קשר קבורים בתפריט, יש בעיית information architecture. לפני כתיבת תוכן חדש, מפו את העמודים שאנשים באמת צריכים ואת הדרך הקצרה אליהם.
אפשר להשתמש ב-הנחיות Google למעבר אתר גם כהכנה: הן מדגישות מיפוי URL-ים, בדיקת קישורים ומעקב אחרי האתר לאחר השינוי.
5. האתר אינו נגיש או קשה לשימוש במקלדת
נגישות אינה “תוספת בסוף הפרויקט”. בדקו ניגודיות, focus, labels לטפסים, alt לתמונות, מבנה כותרות ואפשרות להשלים פעולות בלי עכבר. WCAG 2.2 הוא תקן W3C עם קריטריונים בדיקים; הוא נקודת מוצא טובה, אך אינו תחליף לבדיקה מקצועית ולבדיקת משתמשים.
6. האתר מביא תנועה, אבל לא מוביל לפעולה
לפני שמאשימים את העיצוב, הפרידו בין שלבים: האם אנשים מגיעים לעמוד הנכון? האם ההצעה ברורה? האם יש CTA מתאים? האם הטופס קצר ועובד? האם הפנייה מגיעה למישהו ומקבלת המשך? לעיתים הבעיה היא לא redesign מלא אלא תיקון מסלול ההמרה.
אם אינכם יודעים איפה נשבר המסלול, התחילו ב-נתוני Search Console ובנתוני האנליטיקה שלכם, ולא בהשערות.
7. כל שינוי קטן דורש תלות במפתח או יוצר סיכון
אתר עסקי צריך להיות ניתן לתחזוקה. אם עדכון טקסט, הוספת שירות או בדיקת טופס הם אירוע מורכב — בדקו את ה-CMS, הרשאות העריכה, גיבויים, ניטור ותהליך הפרסום. אתר “חדש” בלי ownership ברור עלול להחזיר את אותה בעיה בעוד שנה.
מה לבדוק לפני שמחליטים על redesign
- אספו את עמודי הכניסה, החיפוש, הפניות והטפסים החשובים.
- בצעו בדיקה נפרדת למובייל, ביצועים, נגישות, תוכן והמרה.
- מפו כל URL ישן לעמוד יעד. שינוי כתובות בלי redirects מתאימים עלול לפגוע בגישה של משתמשים ובסיגנלים של חיפוש; Google ממליצה על redirects קבועים בצד השרת כאשר כתובת השתנתה לצמיתות.
- החליטו מה חייב להישמר, מה דורש שיפור ומה אפשר להסיר.
- הגדירו מדדי הצלחה לפני העיצוב: לא “אתר יפה יותר”, אלא משימות משתמש, פניות, זמן טיפול או תחזוקה קלה יותר.
השורה התחתונה
Redesign מוצדק כאשר האתר יוצר חיכוך מדיד או ברור: מסר לא מובן, שימושיות חלשה, ביצועים, נגישות, מציאת מידע, המרה או תחזוקה. אם הבעיה נקודתית — תקנו נקודתית. אם כמה שכבות נשברו יחד — audit ותוכנית מחדש יהיו בדרך כלל בטוחים יותר מעוד תיקון פלסטר.
למי שרוצה להתחיל בצורה מסודרת: השוו את הבדיקה הזו ל-מדריך ה-UX audit של EzraTech ול-שאלות הבריף לאתר עסקי.