השפעת UI על קידום אתרים: מה גוגל באמת מודדת בעיצוב ובממשק

השפעת UI על קידום אתרים היא אמיתית, אבל היא עוברת דרך כמה ערוצים מוגדרים ולא דרך "כמה האתר יפה". גוגל כותבת שמערכות הדירוג שלה מתגמלות תוכן שמספק חוויית עמוד טובה, ושמדדי Core Web Vitals משמשים את מערכות הדירוג. במקביל, היא מציינת שהיא משתמשת בנתוני אינטראקציה מצטברים ואנונימיים כדי להעריך אם התוצאות רלוונטיות לחיפוש.

בפועל יש חמישה דברים שאפשר לבדוק: כמה מהר העמוד נטען ומגיב, אם הוא קופץ בזמן הטעינה, איך הוא נראה ומתנהג בנייד, אם הגולש מגיע לתוכן בלי שחלונות קופצים ופרסומות מסתירים אותו, ואם האתר מוגש בחיבור מאובטח. ויש גם צד טכני שקשור לממשק, תפריטים וכפתורים שגוגל לא יכולה לסרוק. אם המונחים UI ו-UX עדיין מתערבבים לך, כתבתי הסבר קצר על מה זה UX ומה זה UI שכדאי לקרוא לפני שממשיכים.

סידרתי את הפרקים לפי הסדר שבו כדאי לבדוק, מהמדד שגוגל אומרת במפורש שהוא משמש לדירוג ועד מה שמשפיע בעקיפין.

לפי ההסבר של Google Search Central על חוויית עמוד, אין אות אחד של "חוויית עמוד" (page experience). מערכות הדירוג המרכזיות מסתכלות על מגוון אותות שמתיישרים עם חוויית העמוד הכוללת. גוגל מציעה כמה שאלות לבדיקה עצמית:

• האם לעמודים יש Core Web Vitals טובים?
• האם העמודים מוגשים בצורה מאובטחת?
• האם התוכן מוצג היטב במכשירים ניידים?
• האם התוכן נמנע מכמות מוגזמת של פרסומות שמפריעות לתוכן הראשי?
• האם העמודים נמנעים מחלונות קופצים פולשניים?
• האם העמוד מעוצב כך שהגולש מבחין בקלות בין התוכן הראשי לשאר?

באותו מסמך יש גם שתי הסתייגויות. הראשונה היא שתוצאה טובה בדוח Core Web Vitals לא מבטיחה שהעמוד ידורג בראש התוצאות, ושמרדף אחרי ציון מושלם רק בשביל SEO אולי לא שווה את הזמן. השנייה היא ששאר ההיבטים של חוויית העמוד, מעבר ל-Core Web Vitals, לא עוזרים ישירות לדרג גבוה יותר. הם הופכים את האתר לנעים יותר לשימוש, וזה בדרך כלל מה שמערכות הדירוג מחפשות לתגמל.

זה החלק הכי מדיד בכל הנושא. לפי גוגל, שלושת המדדים והיעדים שלהם הם:

לפי web.dev, כדי לוודא שעומדים ביעד אצל רוב המשתמשים, מודדים את האחוזון ה-75 של טעינות העמוד, בנפרד לנייד ולמחשב.

כדי לראות איפה האתר שלך עומד, יש בסרץ' קונסול דוח Core Web Vitals שמבוסס על נתונים של משתמשים אמיתיים (field data). הוא מחלק קבוצות של כתובות לשלושה מצבים: Poor, Need improvement ו-Good, בנפרד לנייד ולמחשב. לבדיקה של עמוד בודד יש את PageSpeed Insights ואת Lighthouse.

אם המספרים לא טובים, כדאי להתחיל מההחלטות העיצוביות שמכבידות על העמוד: תמונה גדולה בראש העמוד, סליידר, הרבה גופנים, אנימציות ותוספים שמוסיפים סקריפטים. PageSpeed Insights יראה לך איזה אלמנט הוא ה-LCP ומה מאט את העמוד. כתבתי הסבר מפורט על Core Web Vitals ומדריך לשיפור מהירות אתר וורדפרס.

גולש מתחיל לקרוא, ופתאום הטקסט יורד למטה כי נטען באנר. זה CLS, וזו בעיה של ממשק לכל דבר. לפי web.dev, הגורמים הנפוצים ביותר ל-CLS גרוע הם:

• תמונות בלי מידות.
• פרסומות, הטמעות ו-iframe בלי מידות.
• תוכן שמוזרק באופן דינמי, כמו פרסומות והטמעות, בלי מידות.
• גופנים שנטענים מהרשת.

התיקון הוא לוודא שלכל תמונה יש width ו-height, לשמור מקום קבוע לבאנרים ולסרטונים מוטמעים, ולבדוק אם החלפת גופן גורמת לטקסט לזוז. אם אתה משתמש בגוגל פונט, יש כמה הגדרות טעינה שמשפיעות על זה לא מעט.

גוגל משתמשת בגרסת המובייל של האתר, כפי שסורק הסמארטפון שלה רואה אותה, לאינדוקס ולדירוג. לכן העיצוב בנייד הוא העיצוב שגוגל רואה.

כדי לבדוק, פותחים עמוד בנייד ובמחשב ומשווים. אם בנייד הוסתרו פסקאות, כותרות או תמונות כדי "לנקות" את העיצוב, זה בדיוק מה שצריך לתקן.

לפי ההנחיות של גוגל, גרסת המובייל צריכה להכיל את אותו תוכן כמו גרסת המחשב, עם אותן כותרות ברורות. מותר לעצב אחרת: במקום למחוק תוכן כדי לחסוך מקום, גוגל מציעה להעביר אותו לאקורדיונים או ללשוניות. הבסיס לכל זה הוא אתר רספונסיבי אמיתי, ולא רק תבנית שמסתירה אלמנטים במסך קטן.

חלון קופץ של הרשמה לניוזלטר שמכסה את כל המסך בנייד הוא החלטה עיצובית שגוגל מתייחסת אליה ישירות. ההנחיות שלה ממליצות להשתמש בבאנרים שתופסים רק חלק קטן מהמסך במקום חלונות על כל העמוד, כדי שגם הגולש וגם מנוע החיפוש יגיעו לתוכן מיד. היא גם ממליצה, אלא אם זה נדרש על פי חוק, לא לכסות את כל העמוד בחלון ולא להפנות את הגולש לעמוד נפרד כדי לקבל ממנו הסכמה או פרטים.

באותה רשימת בדיקה גוגל שואלת גם אם העמוד מעוצב כך שהגולש מבחין בקלות בין התוכן הראשי לשאר. בפועל צריך לבדוק שהכותרת והתשובה נראות מיד בכניסה, ושהן לא נבלעות בין באנרים, סרגלים צדדיים ואלמנטים שחוזרים בכל עמוד.

כדאי לעבור על כל החלונות הקופצים באתר בנייד. כל מה שמכסה את התוכן מיד בכניסה עובר לבאנר קטן או לנקודה מאוחרת יותר. ואם אתה מציג פרסומות, צריך לבדוק שהן לא דוחקות את התוכן הראשי.

אחת השאלות ברשימת הבדיקה העצמית של גוגל היא אם העמודים מוגשים בצורה מאובטחת. גוגל מפנה בהקשר הזה לבדיקה של החיבור כפי ש-Chrome מדווח עליו, וממליצה לאבטח את האתר ב-HTTPS אם הוא עדיין לא מוגש כך.

הבדיקה פשוטה: פותחים את האתר ב-Chrome ומסתכלים על שורת הכתובת. אם מופיעה אזהרה על חיבור לא מאובטח, הגולש רואה אותה עוד לפני שהוא רואה משהו מהעיצוב. כדאי לבדוק גם עמודים פנימיים וטפסים, ולא רק את עמוד הבית.

צריך לוודא שיש תעודת SSL תקפה, שכל הכתובות באתר מפנות לגרסת ה-HTTPS, ושאין תמונות או סקריפטים שנטענים בכתובת http. אם האזהרה כבר מופיעה, כתבתי הסבר מה עושים כשהאתר מסומן כלא מאובטח.

יש החלטות עיצוב שנראות מצוין לגולש ושגוגל לא רואה בכלל. לפי ההנחיות על קישורים, בדרך כלל גוגל יכולה לסרוק קישור רק אם הוא אלמנט <a> עם מאפיין href. קישור שבנוי כ-span עם href, או כ-<a> שמנווט רק דרך onclick, מופיע אצל גוגל ברשימה של מה שלא מומלץ.

כדי לבדוק, לוחצים בעמוד פתוח לחיצה ימנית על פריט בתפריט ובוחרים ב-Inspect. אם מופיע אלמנט <a> עם href שמכיל כתובת אמיתית, הכול תקין. אם יש div או button שמנווטים בלחיצה, ייתכן שגוגל לא תעקוב אחריהם.

הפתרון הוא לבנות את התפריטים והכפתורים כקישורים רגילים, עם טקסט עוגן שמתאר את העמוד. גוגל מציינת שטקסט הקישור אומר משהו על העמוד שאליו מקשרים, גם לאנשים וגם לה.

גוגל כותבת שהיא משתמשת בנתוני אינטראקציה מצטברים ואנונימיים כדי להעריך רלוונטיות, והופכת אותם לאותות שעוזרים למערכות הלמידה שלה. היא גם כותבת שכאשר שאר האותות דומים, תוכן שנגיש יותר לאנשים עשוי להצליח יותר, ונותנת כדוגמה תוכן שמותאם לנייד ונטען מהר.

מה שגוגל לא מפרסמת הוא נוסחה שמתרגמת מדד מסוים בגוגל אנליטיקס לדירוג. לכן כדאי להתייחס לזמן שהייה או לאחוז מעורבות ככלי לאבחון הממשק, ולא כיעד SEO בפני עצמו. אם גולשים נכנסים ויוצאים מהר, זה סימן לבדוק את העמוד: אם התשובה נמצאת למעלה, אם הכותרת מבטיחה את מה שהעמוד נותן, ואם יש משהו שמפריע לקרוא. על זה כתבתי מאמר על זמן שהייה נמוך באתר.

את הבדיקות כאן אפשר לעשות לבד. כדאי להיעזר במישהו כשדוח Core Web Vitals מראה Poor על קבוצות גדולות של עמודים ולא ברור מה גורם לזה, כשהתבנית או בונה העמודים מייצרים את הבעיה ואין לך גישה נוחה לקוד, כשאתה מתכנן עיצוב מחדש ורוצה לוודא שלא תאבד תנועה בדרך, או כשהתפריטים בנויים בצורה שגוגל לא סורקת.

ואם אתה לפני עיצוב מחדש, כדאי לשמור קודם את מצב הדוחות בסרץ' קונסול: Core Web Vitals, הביצועים בחיפוש ורשימת העמודים שנסרקו. כך יהיה לך למה להשוות אחרי ההעלאה, ותדע מהר אם משהו בעיצוב החדש פגע בתנועה, במקום לגלות את זה אחרי כמה חודשים.

אם אתה רוצה שמישהו יעבור על האתר ויפריד בין מה שבאמת משפיע על הקידום לבין מה שרק נראה טוב, אפשר לפנות אליי.