שבעה מתוך עשרה לקוחות שמגיעים אליי עם ירידה פתאומית בדירוגים, הבעיה האמיתית שלהם לא נמצאת בתוכן או בלינקים. היא נמצאת במובייל. בדיוק שם. בגרסה שאף אחד מהצוות הפנימי שלהם לא בודק באמת, כי "הכל נראה בסדר על האייפון של המנכ"ל". אני גלעד קמר, מנכ"ל WEBS, ומאז 2014 אני רואה את אותה תמונה חוזרת — אתר שנראה מצוין בדסקטופ, נראה סביר במובייל בעין רגילה, ובעיני גוגל הוא שבור לגמרי.
זמן קריאה משוער: 14 דקות | בסוף המדריך מחכה לכם צ'קליסט מלא להורדה
נקודות מפתח מהמדריך הזה
- גוגל מדרג את האתר שלכם לפי גרסת המובייל בלבד — לא הדסקטופ
- תוכן רחב מהמסך אחראי לכ-40% מהבעיות הנפוצות
- חמש בדיקות של חמש דקות חושפות 80% מהתקלות
- ציון PageSpeed של דסקטופ לא שווה כלום — רק המובייל קובע
- תהליך אימות מול גוגל חייב להיעשות אקטיבית אחרי כל תיקון
למה ה-iPhone של המנכ"ל הוא השקר הכי גדול ב-SEO
אני אגיד לכם דבר אחד בוודאות: רוב הבדיקות שעסקים עושים למובייל הן חסרות ערך. בעל העסק פותח את האתר באייפון 15 פרו עם רשת 5G מעולה, רואה שהכל נראה יפה, ומסיק שהאתר מותאם למובייל. זאת טעות שעולה לכם בכסף.
גוגל לא בודק את האתר שלכם מאייפון 15. הוא בודק אותו מ-Moto G Power סימולטיבי על רשת 4G איטית, ומדדי השטח שלו (Field Data) נאספים ממאות אלפי משתמשים אמיתיים עם מכשירים זולים. אם אתם רוצים להבין מה גוגל באמת רואה, תקראו את התיעוד הרשמי של Mobile-First Indexing. זה הבסיס.
חשוב לזכור: הסימנים שיש לכם בעיה אמיתית — ירידה בתנועה אורגנית ספציפית ממובייל (לא מדסקטופ), עלייה ב-bounce rate ממכשירים ניידים, והתראות ב-Search Console על Mobile Usability או Core Web Vitals. אם אחד מאלה קופץ אצלכם, אתם בבעיה.
חמש דקות, חמש בדיקות, אבחון ראשוני שעובד
הצוות שלי עושה את האבחון הראשוני הזה לכל לקוח חדש לפני שאנחנו בכלל מתחילים לדבר על אסטרטגיה. זה לוקח חמש דקות, וזה חושף 80% מהבעיות.
בדיקה 1 — רוחב מסך 320px
פותחים Chrome DevTools, בוחרים Responsive, ומגדירים רוחב ל-320 פיקסל. זה רוחב ה-iPhone SE הישן, וזה עדיין סטנדרט בדיקה. אם משהו "שובר" כאן, יש לכם בעיה.
בדיקה 2 — גלילה אופקית
גוללים את העמוד למטה. אם בכל שלב יש גלילה אופקית בלתי רצויה, יש רכיב שחורג מהרוחב. מצאו אותו.
בדיקה 3 — כפתורים
מנסים ללחוץ על כפתור יצירת קשר, על תפריט המבורגר, על כפתורי שיתוף. האם האצבע "תופסת" מדויק, או שצריך לכוון?
בדיקה 4 — טפסים
פותחים טופס. האם המקלדת מכסה את שדה ההקלדה? האם השדות בגודל סביר?
בדיקה 5 — Search Console
נכנסים לדוח Page Experience ול-URL Inspection. רואים מה גוגל בעצמו אומר. התיעוד של URL Inspection מראה בדיוק אילו סוגי בעיות הכלי מזהה — viewport, font sizes, tap target spacing.
עשיתם את חמש הבדיקות ומצאתם בעיות?
המשיכו לקרוא — בסעיפים הבאים אני מלמד בדיוק איך לתקן כל סוג בעיה
"תוכן רחב יותר מהמסך" — הבעיה שאחראית ל-40% מהדיווחים
זו הבעיה הכי נפוצה שאני רואה בדוחות Mobile Usability. ויש לי סטטיסטיקה פנימית מ-WEBS: מתוך הלקוחות שמגיעים אלינו עם בעיות מובייל, כמעט חצי סובלים מהבעיה הזו לפחות בעמוד אחד.
מה זה אומר בעברית? יש בעמוד שלכם רכיב שהוא רחב יותר מהמסך של המכשיר, וכתוצאה מכך נוצרת גלילה אופקית. החשודים המיידיים שלי, לפי סדר השכיחות: טבלאות ללא wrapping, תמונות עם width קבוע בפיקסלים, iframes (טפסים מוטמעים, מפות גוגל, סרטוני YouTube) שלא הוגדרו רספונסיביים, וכותרות ארוכות מאוד באנגלית בלי break-word.
טיפ מקצועי: כשאתם מחפשים את האשם, השתמשו בקונסול של Chrome עם הקוד הזה: document.querySelectorAll('*').forEach(el => { if (el.offsetWidth > document.documentElement.offsetWidth) console.log(el); }); — זה חושף בשנייה את כל הרכיבים שחורגים.
טקסט קטן מדי, ולמה זה לא רק עניין של גופן
הדיווח "Text too small to read" של גוגל מטעה הרבה אנשים. הם חושבים שמדובר בגודל הפונט, ומגדילים אותו ל-16px. הבעיה ממשיכה. למה? כי הבעיה האמיתית היא לפעמים ה-viewport.
אם תג ה-viewport שלכם לא מוגדר נכון, או בכלל לא קיים, הדפדפן עושה זום אאוט אוטומטי לכל העמוד כדי להציג אותו. התוצאה: גם פונט של 18px נראה כמו 9px. אני ממליץ לקרוא את המדריך של web.dev על רספונסיביות, במיוחד את החלק על viewport meta tag.
ההגדרה הנכונה? <meta name="viewport" content="width=device-width, initial-scale=1">. בלי maximum-scale (זה פוגע בנגישות), בלי user-scalable=no. פשוט, נקי, עובד.
מעבר ל-viewport, יש את עניין הקריאות עצמה. גוף הטקסט צריך להיות 16px ומעלה. line-height סביב 1.5-1.6. ניגודיות צבעים שעוברת את WCAG AA לפחות. אם אתם רוצים להעמיק, התקן הישראלי SI 5568-1 מפרט את הדרישות המדויקות.
המלצה: בדקו את הניגודיות של הצבעים באתר שלכם בכלי חינמי כמו WebAIM Contrast Checker. גם טקסט בגודל מושלם לא יעזור אם הצבע שלו נבלע ברקע.
אלמנטים לחיצים קרובים מדי, או למה הפוטר שלכם הוא מלכודת
תסתכלו על הפוטר של האתר שלכם במובייל. כנראה שיש שם ארבע עמודות צפופות עם 30 קישורים, וכל קישור הוא טקסט בגודל 12px עם 4px padding. ועכשיו תנסו ללחוץ עליהם עם אגודל אמיתי. בהצלחה.
גוגל מגדיר את הסטנדרט די ברור. המדריך הרשמי על Accessible Tap Targets ממליץ על אזור לחיצה של 48×48 פיקסלים מינימום, עם רווח של 8 פיקסלים לפחות בין אזורי לחיצה סמוכים. זה לא קישוט, זה מדידה.
איפה רואים את הבעיה הזו הכי הרבה?
- תפריט המבורגר עם קישורים צמודים
- פוטר עם ארבע עמודות במובייל (זה צריך להיות עמודה אחת)
- כפתורי שיתוף ברשתות חברתיות שדבוקים זה לזה
- פאגינציה של "1 2 3 4 5 הבא" עם מספרים זעירים
פעולה מיידית: פתחו את הפוטר שלכם במובייל עכשיו. ספרו כמה עמודות יש. אם יש יותר מאחת, יש לכם בעיה. תיקון: media query שמשנה את ה-grid לעמודה אחת מתחת ל-768px, ומגדיל את הגובה של כל קישור ל-44px לפחות.
איך מאתרים את הרכיב ש"שובר" את המובייל בלי לנחש
שיטת ה-Border האדום
השיטה הכי מהירה שאני מכיר. פותחים את ה-Console ב-DevTools, ומדביקים: document.querySelectorAll('*').forEach(el => el.style.outline = '1px solid red');. עכשיו כל אלמנט מקבל מסגרת אדומה, ואתם רואים בדיוק איזה רכיב חורג. זה נראה כמו תקלה במטריקס, אבל זה עובד.
בידוד עם overflow-x
השיטה השנייה: מוסיפים זמנית html { overflow-x: hidden; } ב-CSS. עכשיו אם הגלילה האופקית נעלמת, אתם יודעים שהבעיה היא ברכיב שחורג. עכשיו עוברים אלמנט-אלמנט עם DevTools ומחפשים מי האשם.
חשוב לזכור: overflow-x: hidden הוא רק כלי אבחון, לא פתרון. אסור להשאיר את זה בקוד פרודקשן כי זה מסתיר את הבעיה במקום לפתור אותה.
סיכום ביניים:
עד כאן כיסינו את שלוש הבעיות הנפוצות ביותר — תוכן רחב, טקסט קטן, ואלמנטים לחיצים צפופים — יחד עם שיטות איתור מעשיות. מכאן נעבור לביצועים: מהירות, תמונות, ו-Core Web Vitals.
Core Web Vitals במובייל, ולמה הציון של הדסקטופ לא מעניין אף אחד
תאמינו לי, עשיתי את הטעות הזו בעצמי בתחילת הדרך. רואים ציון 95 ב-PageSpeed Insights ושמחים. אבל הציון הזה היה לדסקטופ. כשעברתי לטאב Mobile, הציון היה 34. וזה הציון שמשנה.
שלושת המדדים שאתם צריכים להכיר:
- LCP (Largest Contentful Paint) — כמה זמן לוקח לאלמנט הכי גדול בעמוד להיטען, צריך להיות מתחת ל-2.5 שניות
- INP (Interaction to Next Paint) — כמה זמן לוקח לעמוד להגיב לאינטראקציה של המשתמש, צריך להיות מתחת ל-200ms
- CLS (Cumulative Layout Shift) — כמה הפריסה "קופצת" בזמן הטעינה, צריך להיות מתחת ל-0.1
ה-המתודולוגיה המלאה של הספים זמינה ב-web.dev, ואני ממליץ לכל מי שעוסק ב-SEO טכני לקרוא אותה. גוגל לא המציא את המספרים מהראש, יש שם מחקר שלם.
טיפ מקצועי: בדקו תמיד את הטאב "Mobile" ב-PageSpeed Insights, לא את הדסקטופ. ציון 95 בדסקטופ עם 34 במובייל משמעו שהאתר שלכם איטי בעיני גוגל.
תמונות במובייל, או איך לחסוך 70% במשקל בלי לאבד חדות
סיפור אמיתי. לקוח שלי בתחום האופנה. הדף הראשי שלו שקל 8.2MB במובייל. שמונה. אחרי שעברנו על הקוד, גילינו שהוא מגיש את אותן תמונות 2400px רוחב גם לסמארטפון של 375px. בום, פתאום הדפדפן מוריד 2.5MB של תמונה רק כדי להציג אותה ב-1/6 מהגודל.
הפתרון הוא srcset ו-sizes, ויש מדריך מצוין של web.dev על איך ליישם את זה נכון. בקצרה: מספקים לדפדפן כמה גרסאות של אותה תמונה בגדלים שונים, והוא בוחר את המתאימה למסך. אחרי שעשינו את זה אצל הלקוח, הדף ירד מ-8.2MB ל-2.1MB. LCP ירד מ-4.8 שניות ל-1.9 שניות. הדירוגים עלו תוך 6 שבועות.
חשוב לזכור: שימוש ב-loading="lazy" על תמונת ה-Hero שמעל הקפל הורג את ה-LCP. lazy loading נועד לתמונות שמתחת לקפל, לא מעליו.
כבר עברנו את חצי המדריך
עוד לפניכם: פופאפים, breakpoints, אימות מול גוגל, והצ'קליסט המלא
פופאפים ואינטרסטישיאלס, או למה גוגל שונא את האחים ההם
זה הסעיף שכל לקוח שני מתווכח איתי עליו. "אבל הפופאפ מביא לי לידים." אני מבין. אני באמת מבין. אבל גוגל מבין גם, וההנחיות שלו ב-Avoid Intrusive Interstitials ברורות: פופאפ שמכסה את התוכן במובייל מיד עם הכניסה לעמוד, יפגע בדירוג שלכם.
מה מותר?
- באנר עוגיות (Cookie Banner) חוקי
- פופאפ אימות גיל
- פופאפ שמופיע אחרי גלילה משמעותית או אחרי 30 שניות
מה אסור?
- פופאפ שמופיע מיד בכניסה ומכסה 50% מהמסך
- פופאפ שאי אפשר לסגור בקלות
- באנר ניוזלטר שתופס חצי מסך
גוגל לא מעניש אתכם על שיווק. הוא מעניש אתכם על שיווק רע.
איך לתקן Breakpoints בלי לשבור את הדסקטופ
זו הסיבה הכי נפוצה שמפתחים פוחדים לגעת בקוד CSS של אתר קיים. מתקנים משהו במובייל, ובום, הדסקטופ נשבר. אני אתן לכם את השיטה שלי.
הכלל הראשון: עובדים Mobile-First
כלומר, ה-CSS הבסיסי שלכם מתאר את המובייל, ו-media queries מוסיפים שינויים עבור מסכים גדולים יותר. @media (min-width: 768px) ולא @media (max-width: 767px). זה משנה את כל החשיבה.
הכלל השני: Breakpoints סטנדרטיים
480px, 768px, 1024px, 1280px. אל תמציאו breakpoints חדשים. ככל שיש פחות breakpoints, הקוד יותר יחזיק.
הכלל השלישי: CSS Grid ו-Flexbox
השתמשו ב-CSS Grid וב-Flexbox במקום ב-floats ובפוזישנים אבסולוטיים. הם מטפלים ברספונסיביות בצורה הרבה יותר חכמה.
המלצה: לפני כל שינוי ב-CSS, צלמו screenshots של 5 עמודים מרכזיים ב-3 רוחבי מסך (375px, 768px, 1440px). אחרי השינוי, השוו. כך תתפסו שבירות לפני שהן מגיעות לפרודקשן.
איך מאמתים שהתיקון עבד, ושגוגל ראה אותו
פה רוב האנשים נופלים. הם מתקנים את הבעיה, ומחכים. שבועיים אחר כך הם בודקים ב-Search Console ורואים שהדיווח עדיין שם. למה? כי הם לא ביקשו מגוגל לסרוק מחדש.
התהליך הנכון, צעד אחר צעד:
- אחרי התיקון, רצים על PageSpeed Insights בטאב Mobile, ומוודאים שהציון השתפר
- נכנסים ל-URL Inspection ב-Search Console, מקלידים את ה-URL, ולוחצים על "Test Live URL"
- אם הכל נראה תקין, לוחצים על "Request Indexing". המדריך הרשמי על Recrawl מסביר את התהליך
טיפ מקצועי: Request Indexing הוא לעמוד אחד בכל פעם. אם תיקנתם בעיה שמשפיעה על כל האתר (למשל, בעיית viewport או CSS גלובלי), לא צריך לבקש לכל עמוד בנפרד. גוגל יסרוק מחדש בקצב שלו, ותראו את השיפור תוך 1-3 שבועות.
הטעות שכמעט כל סוכנות עושה, ואיך אנחנו עובדים אחרת
רוב הסוכנויות בודקות את האתר פעם אחת בהתחלה, מתקנות מה שצריך, ומסיימות. ואז שלושה חודשים אחר כך מישהו מעלה תמונה גדולה למאמר חדש, או מתקין פלאגין שמוסיף סקריפט כבד, וכל העבודה הולכת לפח. אף אחד לא יודע על זה עד שהדירוגים יורדים.
בצוות שלי אנחנו עובדים אחרת. מערכת WEBFORCE שפיתחנו פנימית סורקת את האתרים של הלקוחות שלנו ברציפות, ומזהה בזמן אמת מתי משהו השתנה. תמונה חדשה ששוקלת 4MB? מקבלים התראה. ציון Core Web Vitals שירד מעל 10%? מקבלים התראה. בעיית Mobile Usability חדשה ב-Search Console? מקבלים התראה. זה מאפשר לנו לתקן לפני שגוגל מספיק להעניש.
אנחנו מומחים בקידום אורגני בלבד, וזה מה שהופך אותנו לייחודיים. אין לנו צוות מדיה ממומנת שלוחץ עליכם לפזר כסף בגוגל אדס. אין לנו התחייבות חודשית, אתם נמצאים איתנו כל עוד אתם מרוצים. ללא אותיות קטנות.
מתי כדאי לבנות אתר מובייל נפרד, ומתי זה רעיון רע
שאלה שאני מקבל הרבה. התשובה הקצרה: כמעט אף פעם.
בעבר היה נפוץ לבנות m.example.com נפרד. היום זה כמעט תמיד טעות. גוגל ממליץ בפירוש על Responsive Design, וזה מה שעובד הכי טוב. אתר נפרד למובייל מייצר בעיות של duplicate content, בעיות של canonical, ובעיות תחזוקה (כל שינוי צריך להיעשות פעמיים).
המלצה: מתי כן לשקול אתר נפרד? במקרים מאוד נדירים של אפליקציות ווביות מורכבות מאוד, או כשהפונקציונליות במובייל ובדסקטופ באמת שונה לחלוטין. אבל לעסק רגיל, לחנות אינטרנטית, לאתר תדמית? תמיד responsive.
הצ'קליסט שאני נותן לכל לקוח חדש
אחרי 12 שנים בתחום, צמצמתי את האבחון הראשוני ל-10 דברים שכל אתר חייב לעבור. אם כל ה-10 ירוקים, אתם במצב טוב. אם אחד אדום, יש מה לתקן.
- viewport meta tag מוגדר נכון
- אין גלילה אופקית ב-320px
- כל הכפתורים בגודל 48×48 מינימום
- טקסט בגודל 16px ומעלה
- תמונות עם srcset ו-sizes
- אין פופאפים אגרסיביים בכניסה
- LCP מתחת ל-2.5 שניות במובייל
- CLS מתחת ל-0.1
- אין שגיאות Mobile Usability ב-Search Console
- טפסים פונקציונליים ונוחים במובייל
בשורה התחתונה, פתרון בעיות מובייל ב-SEO זה לא פרויקט חד פעמי. זה תהליך מתמשך. אבל אם תעקבו אחרי המתודולוגיה הזו, תהיו לפני 95% מהמתחרים שלכם.
רוצים לדעת אם האתר שלכם באמת מותאם למובייל?
או רק נראה כזה על האייפון של המנכ"ל? צרו קשר עם הצוות שלנו לאבחון ראשוני ללא התחייבות.
הצעדים הבאים שלכם:
- עשו את חמש הבדיקות המהירות שתיארנו — היום
- בדקו את ציון ה-Mobile של PageSpeed Insights לעמוד הבית ולשני עמודים מרכזיים
- היכנסו ל-Search Console ובדקו דוח Mobile Usability
- אם מצאתם בעיות — תקנו לפי הסדר שמופיע במדריך, או פנו אלינו לאבחון מקצועי
גלעד קמר, מנכ”ל ומייסד וובס – חברה לקידום אתרים באינטרנט.
אני מביא איתי ניסיון של למעלה מ-12 שנים בתחום הקידום האורגני והמון יצירתיות וחשיבה מחוץ לקופסה.
