אינדוקס Mobile-First ב-2026: המשמעות האמיתית של 'לנייד בלבד'

התשובה הקצרה

אינדוקס Mobile-First הסתיים. מאז יולי 2024, Google משתמשת רק בגרסת המובייל של האתר שלך לאינדוקס ודירוג. אם תוכן, נתונים מובנים או קישורים פנימיים קיימים בדסקטופ אך לא במובייל, Google לא רואה אותם. בשנת 2026, יש לכך שלוש השלכות חדשות שרוב בעלי האתרים טרם טיפלו בהן: INP החליף את FID כמדד Core Web Vital, AI Overviews שואבות מתוכן מעובד במובייל, ועדכון הליבה של מרץ 2026 הגביר את משקל הדירוג של חוויית דף המובייל.

להלן תמצאו זרימת עבודה מלאה לביקורת — ומיומנות Codex להעתקה-הדבקה שמריצה את רוב הבדיקות עבורכם.

מה המשמעות האמיתית של "לנייד בלבד" ב-2026

Google החלה להעביר אתרים לאינדוקס Mobile-First בשנת 2018. המעבר ארך יותר משש שנים. החל מיולי 2024, כל אתר שעדיין היה לו תוכן נגיש בדסקטופ ללא מקבילה במובייל איבד את התוכן הזה מהאינדקס של Google. אין אפשרות ביטול ואין גיבוי לדסקטופ בלבד.

אבל הסיפור לא נגמר שם. שלושה שינויים בשנים 2025–2026 שינו את מה ש-"Mobile-First" דורש מהאתר שלכם:

שינוי 1: INP החליף את FID — ורוב אתרי המובייל נכשלים בו

במרץ 2024, Google החליפה את First Input Delay (FID) ב-Interaction to Next Paint (INP) כמדד Core Web Vital. INP מודד כמה מהר הדף שלכם מגיב להקשות, קליקים ולחיצות מקשים לאורך כל סשן הדף, לא רק באינטראקציה הראשונה.

המספר הקשה: בערך 40% מהאתרים שעברו FID לא עוברים INP. במובייל, רק כ-65% מהאתרים עומדים בסף ה"טוב" של 200 אלפיות השנייה או פחות. עדכון הליבה של מרץ 2026 הגביר עוד יותר את משקל הדירוג של Core Web Vitals. אתרים שנכשלים ב-INP במובייל מאבדים כעת מיקומים למתחרים מהירים יותר.

שינוי 2: AI Overviews וסורקי AI קוראים את תוכן המובייל שלכם

AI Overviews של Google מופיעות בכ-47% מהחיפושים נכון לאמצע 2026. כאשר מערכות ה-AI של Google מייצרות תשובות, הן שואבות מאותו תוכן באינדקס המובייל שבו משתמש החיפוש הרגיל. סורקי AI של צד שלישי (GPTBot, ClaudeBot, PerplexityBot) ניגשים גם הם לדפי המובייל המעובדים שלכם.

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

שינוי 3: לפערי שוויון תוכן יש כעת השפעת דירוג מדידה

בשנת 2026, אתרים עם תוכן לא עקבי בין מובייל לדסקטופ מראים חשיפה אורגנית נמוכה ב-31.2% בממוצע בהשוואה לאתרים עם שוויון תוכן מלא. האלמנטים החסרים הנפוצים ביותר במובייל: תוכן טאבים מוסתר, קישורי סרגל צד, סימון נתונים מובנים, טקסט alt לתמונות וקישורי ניווט פנימיים.

כיצד לבדוק אם האתר שלכם עובר (גרסת 2 דקות)

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

איתות 1: סטטוס אינדוקס ב-Google Search Console

פתחו את Google Search Console ← לחצו על Settings (אייקון גלגל שיניים, למטה משמאל) ← הסתכלו תחת סעיף "About". אם כתוב "Googlebot smartphone" תחת "Indexing crawler", האתר שלכם נמצא באינדוקס Mobile-First. זה נכון למעשה לכל אתר ב-2026 — אבל ודאו זאת.

בדקו גם: כלי בדיקת URL ← הזינו כל דף חשוב ← הרחיבו את "Crawl" ← אשרו "Crawled as: Googlebot smartphone." הסתכלו בצילום המסך ש-Google מספקת — זה בדיוק מה ש-Google רואה. אם תוכן מפתח חסר מצילום מסך זה, הוא חסר מהאינדקס.

איתות 2: PageSpeed Insights עם נתוני מובייל אמיתיים

גשו ל-PageSpeed Insights, הזינו את ה-URL שלכם, והסתכלו בסעיף "Discover what your real users are experiencing". אלה נתוני שטח מ-Chrome User Experience Report (CrUX) — אותם נתונים ש-Google משתמשת לדירוג.

אם דוח המובייל מראה כתום או אדום עבור INP (Interaction to Next Paint), יש לכם חבות דירוג פעילה. הסף הוא מתחת ל-200 אלפיות השנייה לירוק.

איתות 3: בדיקה מהירה של תצוגת מובייל ב-Chrome DevTools

פתחו את Chrome DevTools (F12 או Cmd+Option+I), לחצו על אייקון סרגל כלי המכשיר (Ctrl+Shift+M), ובחרו הגדרה מוכנה של מכשיר נייד כמו "Pixel 7." רעננו את הדף. סרקו אחר:

• טקסט הדורש גלילה אופקית
• כפתורים או קישורים קטנים מדי להקשה (מתחת ל-48×48 פיקסלים CSS)
• תוכן מוסתר מאחורי מתגי "קרא עוד" שאינם בקוד המקור HTML
• חלונות קופצים המכסים את רוב המסך

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

ביקורת Mobile-First ב-30 דקות (עם Codex)

הדרך המהירה ביותר להריץ ביקורת Mobile-First מלאה כיום היא לתת לסוכן קידוד AI — Claude Code או Codex — משימה מובנית. הסוכן קורא את מקור האתר שלכם, בודק את הכללים ומייצר רשימת תיקונים לפי עדיפות.

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

שלב 1: צרו את קובץ המיומנות

צרו קובץ בנתיב .claude/skills/mobile-first-audit/SKILL.md (עבור Claude Code) או .codex/skills/mobile-first-audit/SKILL.md (עבור Codex):

name: mobile-first-audit
description: בדיקת URL או רשימת URLs למוכנות לאינדוקס Mobile-First. בודק שוויון תוכן, Core Web Vitals, נתונים מובנים, UX מובייל וגישת סורקי AI.

# ביקורת אינדוקס Mobile-First

הריצו ביקורת אינדוקס Mobile-First מובנית על URL אחד או יותר. על הסוכן לדווח ממצאים, לא לבצע עריכות, אלא אם המשתמש מאשר במפורש תוכנית תיקונים.

## קלט

המשתמש מספק URL אחד או יותר של דפים. אם הוא מספק URL של מפת אתר או רשימה של יותר מ-5 כתובות URL, דגמו 5 כתובות URL המייצגות סוגי דפים שונים (דף בית, דף מוצר, מאמר, דף קטגוריה, דף נחיתה).

## רשימת בדיקה

עבור כל URL, בדקו ודווחו על כל אחד עשר הפריטים להלן. סמנו כל פריט כ-`PASS`, `WARN` או `FAIL`. כללו את הראיה לכל WARN ו-FAIL.

### 1. תגית Meta Viewport
בדקו ש-`<meta name="viewport" content="width=device-width, initial-scale=1">` קיים ב-`<head>` של ה-HTML. אם חסר או אם הוא מגדיר רוחב קבוע או מבטל scaling משתמש ללא סיבת נגישות תקפה, סמנו FAIL.

### 2. שוויון תוכן (טקסט)
הביאו את הדף עם user-agent דסקטופ ו-user-agent מובייל (Googlebot Smartphone). השוו את תוכן הטקסט הגלוי. אם בלוק טקסט כלשהו מעל 50 מילים קיים בדסקטופ אך לא במקור ה-HTML של המובייל, סמנו WARN. אם טקסט גוף חשוב, כותרות או תיאורי מוצר חסרים, סמנו FAIL.

### 3. שוויון נתונים מובנים
חלצו את כל בלוקי ה-JSON-LD משתי ההבאות של דסקטופ ומובייל. אם סוג schema כלשהו הקיים בדסקטופ חסר במובייל, סמנו FAIL. אם תוכן schema שונה בין הגרסאות, סמנו WARN.

### 4. שוויון תגיות Meta
השוו תגיות title, meta description, canonical, robots ו-hreflang בין גרסת הדסקטופ למובייל. כל הבדל הוא WARN. חוסר canonical או תגית robots סותרת היא FAIL.

### 5. קישורים פנימיים וניווט
ספרו את מספר תגי `<a href>` לקישורים פנימיים ב-HTML של דסקטופ ומובייל. אם לגרסת המובייל יש 20%+ פחות קישורים פנימיים, סמנו WARN. אם קישורי breadcrumb, ניווט קטגוריות או קישורי footer הקיימים בדסקטופ חסרים במובייל, סמנו FAIL.

### 6. טקסט Alt לתמונות
ספרו תמונות ב-HTML המובייל. דווחו על המספר ואחוז החסרות במאפייני alt. אם יותר מ-10% מהתמונות חסרות טקסט alt, סמנו WARN. אם תמונות hero או תמונות מוצר חסרות טקסט alt, סמנו FAIL.

### 7. Core Web Vitals (נתוני שטח)
חפשו נתוני שטח של Chrome UX Report (CrUX) עבור ה-URL. אם נגיש דרך PageSpeed Insights API או חיפוש CrUX ישיר, דווחו על LCP, INP ו-CLS למובייל. ספי סימון: LCP > 2.5s = WARN, > 4.0s = FAIL. INP > 200ms = WARN, > 500ms = FAIL. CLS > 0.1 = WARN, > 0.25 = FAIL.

אם נתוני CrUX אינם זמינים (תנועה לא מספקת), ציינו זאת והשתמשו בנתוני מעבדה מ-Lighthouse כגיבוי עם ההסתייגות שנתוני מעבדה אינם משמשים לדירוג.

### 8. גודל יעדי הקשה
בדקו CSS עבור כפתורים, קישורים ואלמנטים אינטראקטיביים. סמנו כל אלמנט שהגובה או הרוחב המחושב שלו מתחת ל-48 פיקסלים CSS. סמנו אלמנטים אינטראקטיביים סמוכים עם מרווח קטן מ-8px. סמנו WARN עבור 1-3 הפרות, FAIL עבור 4+.

### 9. גודל גופן
בדקו שטקסט גוף משתמש בגודל גופן מחושב של לפחות 16px. סמנו כל טקסט מתחת ל-12px. סמנו WARN אם טקסט גוף הוא 14-15px, FAIL אם מתחת ל-12px.

### 10. חלונות ביניים וחלונות קופצים
בדקו ויזואלית את תצוגת המובייל. אם חלון קופץ, באנר או חלון ביניים מכסה יותר מ-30% מתצוגת המסך הראשונית ואינו נדרש חוקית (הסכמת עוגיות, אימות גיל), סמנו WARN. אם החלון הקופץ מונע גלילה או קריאת תוכן, סמנו FAIL.

### 11. גישת סורקי AI
בדקו robots.txt לחוקים החוסמים GPTBot, ClaudeBot, PerplexityBot, Google-Extended או OAI-SearchBot. אם סורק AI כלשהו חסום, ציינו זאת כבחירה מכוונת. אם סורקי AI מורשים אך לדף אין נתונים מובנים, סמנו WARN (מערכות AI מסתמכות על נתונים מובנים לציטוטים).

## פורמט פלט

הפיקו דוח Markdown:

```markdown
# דוח ביקורת Mobile-First
**תאריך:** YYYY-MM-DD
**מספר URLs שנבדקו:** N
**ציון כולל:** X/11 פריטי PASS בממוצע ל-URL

## סיכום

| בדיקה | URL 1 | URL 2 | URL 3 | URL 4 | URL 5 |
|-------|-------|-------|-------|-------|-------|
| 1. Viewport | PASS | PASS | ... | ... | ... |
| ... | ... | ... | ... | ... | ... |

## ממצאים מפורטים

### URL 1: [url]

**פריטי FAIL (חובה לתקן):**
- [שם פריט]: [ראיה והוראות תיקון]

**פריטי WARN (כדאי לתקן):**
- [שם פריט]: [ראיה והוראות תיקון]

**פריטי PASS:** [רשימה]

### תור עדיפויות לתיקונים

1. [תיקון בעדיפות עליונה] — משפיע ישירות על אינדוקס
2. [התיקון הבא] — משפיע על דירוג
3. ...

כללים

• אל תבצעו שום שינוי באתר ללא אישור מפורש של המשתמש לתוכנית התיקונים.
• אם אינכם יכולים לבדוק פריט מכיוון שהדף דורש אימות, ציינו זאת כ-"NOT CHECKED — authentication required."
• עבור נתוני CrUX, השתמשו ב-Chrome UX Report API הרשמי או PageSpeed Insights API אם זמין. אם אף אחד מהם אינו נגיש, השתמשו בביקורת Lighthouse למובייל כגיבוי.
• לעולם אל תמציאו מדדים, ציונים או תוצאות בדיקה. אם נתונים אינם זמינים, אמרו זאת.
• אל תגשו או תח�פו מפתחות API, עוגיות, טוקנים או פרטי גישה.

### שלב 2: הריצו את הביקורת

בקשו מהסוכן שלכם להריץ את פקודת הביקורת הבאה עם ה-URL הרצוי:

```text
Run the mobile-first audit skill on [your URL]

הסוכן יפיק דוח עם PASS/WARN/FAIL עבור כל אחת מ-11 הבדיקות, בתוספת תור עדיפויות לתיקונים.

לבדיקת מספר דפים במקביל, השתמשו בפקודה הבאה:

Run the mobile-first audit on these 5 URLs: [URL1, URL2, URL3, URL4, URL5]

תיקון #1: שוויון תוכן — מה לבדוק קודם

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

תוכן מוסתר בטאבים ואקורדיון

אתרים רבים במובייל מקפלים תוכן ארוך לטאבים, אקורדיון או מתגי "קרא עוד". זה בסדר כל עוד התוכן נמצא בקוד המקור HTML — Google כבר לא מפחיתה מערך תוכן המוסתר מסיבות UX. אבל אם הטאבים שלכם טוענים תוכן דרך JavaScript לאחר הקשה של משתמש, Googlebot לא מפעיל הקשה זו. התוכן בלתי נראה.

כיצד לבדוק: ב-Chrome DevTools, לחצו קליק ימני על תוכן מוסתר ובחרו "Inspect." אם אתם רואים את הטקסט בחלונית Elements, הוא ב-DOM ו-Google יכולה לראות אותו. אם חלונית Elements מראה מיכל ריק עד שתלחצו על הטאב, התוכן נטען דינמית ו-Google מפספסת אותו.

כיצד לתקן: עבדו בצד השרת את התוכן המוסתר לתוך ה-HTML. השתמשו ב-CSS (display: none או מתגי visibility) להתנהגות הצגה/הסתרה במקום הזרקת תוכן ב-JavaScript.

נתונים מובנים חסרים במובייל

נתונים מובנים (JSON-LD) חייבים להיות נוכחים ב-HTML של המובייל. קל לפספס זאת אם תבנית המובייל או גרסת ה-AMP שלכם משתמשת בתבנית שונה.

כיצד לבדוק: פתחו את דף המובייל, הציגו מקור (Cmd+Option+U), וחפשו application/ld+json. לאחר מכן עשו את אותו הדבר בדסקטופ. אותם בלוקי JSON-LD צריכים להופיע בשניהם.

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

קישורי ניווט שהוסרו מתפריטי מובייל

תפריטי מובייל לעיתים קרובות מפשטים או מסירים קישורים הקיימים בניווט הדסקטופ: breadcrumbs, קישורי קטגוריות, עמודות footer, קישורי סרגל צד. Google משתמשת בקישורים פנימיים להבנת מבנה האתר ולהפצת PageRank. קישורים החסרים במובייל חסרים בגרף של Google.

כיצד לבדוק: ספרו את תגי <a href> במקור הדסקטופ מול מקור המובייל. עיצוב רספונסיבי צריך להיות בעל מספרים שווים בערך. אם ספירת המובייל נמוכה ב-30%+, בדקו אילו קישורים נעלמו.

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

תיקון #2: INP — מדד מהירות המובייל שרוב האתרים מתעלמים ממנו

Interaction to Next Paint (INP) מודד כמה זמן לוקח לדף להגיב ויזואלית לאחר שמשתמש מקיש, לוחץ או לוחץ על מקש. הסף הוא 200 אלפיות השנייה או פחות.

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

מה הורג INP במובייל

הגורמים הנפוצים ביותר, לפי סדר:

1. JavaScript כבד רץ על ה-thread הראשי. חבילות גדולות, רכיבי React/Vue לא אופטימליים וסקריפטי מעקב חוסמים את הדפדפן מלהגיב להקשות.
2. מטפלי קליק שעושים יותר מדי עבודה לפני עדכון ה-UI. אם הקשה מפעילה קריאת API, עדכון state ושינוי DOM לפני הצגת משוב ויזואלי כלשהו, INP נפגע.
3. תגיות צד שלישי. אנליטיקה, ווידג'טים של צ'אט, רשתות פרסום וסקריפטי פרסונליזציה — במיוחד כשמספר תגיות מתחרות על ה-thread הראשי.

כיצד לאבחן INP

1. פתחו את PageSpeed Insights, הזינו את ה-URL שלכם, גללו לסעיף נתוני המשתמשים האמיתיים (CrUX). ערך ה-INP תחת "Mobile" הוא מה ש-Google משתמשת בו.
2. ב-Chrome DevTools, פתחו את חלונית Performance, לחצו על record, תקשרו עם הדף (הקישו כפתורים, פתחו תפריטים, הקלידו בשדות), ואז עצרו את ההקלטה. חפשו משימות ארוכות (מסומנות באדום, 200ms+). אלה בעיות ה-INP שלכם.
3. תוכלו גם לבקש מהסוכן AI שלכם להריץ את הפקודה הבאה:

Check the Core Web Vitals for [URL] and tell me specifically what is hurting INP on mobile. Give me the top 3 fixes in priority order.

כיצד לתקן INP (סדר עדיפויות)

עדיפות 1: דחו או עכבו סקריפטי צד שלישי לא קריטיים.
  → טענו ווידג'טים של צ'אט, אנליטיקה ותגיות פרסום לאחר שהדף אינטראקטיבי.
  → השתמשו ב-<script defer> או טענו אותם 3-5 שניות לאחר טעינת הדף.

עדיפות 2: פרקו משימות JavaScript ארוכות.
  → פצלו קוד לפי route. טענו בעצלתיים רכיבים מתחת לקפל.
  → העבירו חישוב כבד ל-requestIdleCallback() או Web Worker.

עדיפות 3: גרמו למטפלי קליק לעדכן את ה-UI מיד.
  → הציגו מצב טעינה, ספינר או כפתור מושבת ב-50ms הראשונות.
  → הריצו את העבודה האמיתית (קריאת API, עדכון state) לאחר התגובה הוויזואלית.

תיקון #3: מוכנות לסורקי AI (שכבת 2026)

לאינדוקס Mobile-First יש כעת שכבת AI. כאשר AI Overviews של Google או מערכות AI של צד שלישי עונות על שאלה, הן שואבות מאותו תוכן באינדקס המובייל. אם דפי המובייל שלכם חסרים את האותות שמערכות AI מחפשות, אתם מאבדים ציטוטים.

מה מערכות AI צריכות מדפי המובייל שלכם

פקודת מוכנות AI מהירה לסוכן שלכם

Check [URL] for AI search readiness. Tell me: (1) is JSON-LD structured data present and valid? (2) is there a clear answer to the page's main question in the first 200 words? (3) are AI crawlers allowed in robots.txt? (4) does llms.txt exist at the root? Give me a PASS/FAIL for each and tell me what to fix first.

פקודות ביקורת Mobile-First מלאות למתחילים

להלן סט פקודות שתוכלו להעתיק ל-Claude Code או Codex מיד. כל פקודה מבצעת משימה ספציפית אחת — אין צורך בתצורה מעבר לפתיחת הסוכן והפנייתו לפרויקט או ל-URL שלכם.

פקודה 1: ביקורת מובייל לדף יחיד

Run a mobile-first indexing audit on [YOUR URL HERE].

Check these 8 things and report PASS or FAIL for each with the evidence:
1. Viewport meta tag is correct
2. All body text visible on desktop is also in the mobile HTML source
3. JSON-LD structured data is the same on desktop and mobile
4. Title tag, meta description, and canonical are identical across desktop and mobile
5. Internal link count is roughly equal (not 20%+ fewer on mobile)
6. Images have alt text
7. Mobile Core Web Vitals (LCP, INP, CLS) from CrUX field data if available
8. AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) are not blocked in robots.txt

For each FAIL, give me the exact fix in one sentence.

פקודה 2: ביקורת גורפת על פני סוגי דפים

I need to audit mobile-first readiness across different page types on my site. Here are 5 URLs, each representing a different template:

1. [HOMEPAGE URL]
2. [PRODUCT PAGE OR SERVICE PAGE URL]
3. [BLOG POST OR ARTICLE URL]
4. [CATEGORY OR COLLECTION PAGE URL]
5. [ABOUT OR CONTACT PAGE URL]

For each URL, check: viewport meta tag, content parity (text + structured data), meta tags consistency, internal links, image alt coverage, and mobile font/tap-target sizing.

Then produce a single table with all 5 URLs as columns and each check as a row. Color-code PASS green, WARN yellow, FAIL red (use emoji 🟢 🟡 🔴 if colors are not supported). Below the table, list the top 3 fixes across all pages in priority order.

פקודה 3: צלילה עמוקה לשוויון תוכן

Fetch [URL] with both a desktop user-agent and the Googlebot Smartphone user-agent (Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)).

Compare the two versions and report any differences in:
- Visible text content (highlight blocks missing from mobile)
- Structured data (JSON-LD blocks)
- Meta tags (title, description, canonical, robots, hreflang)
- Internal link count and which sections lost links
- Image alt attributes

Do not make any edits. Just produce a diff report.

פקודה 4: אבחון INP ותוכנית תיקון

Analyze [URL] for Interaction to Next Paint (INP) issues on mobile.

1. Check if CrUX field data is available and report the current mobile INP value.
2. If CrUX data is unavailable, run a Lighthouse mobile audit and report the Total Blocking Time (TBT) as a proxy indicator.
3. Identify the top 3 JavaScript tasks blocking the main thread during page load and after user interaction.
4. For each problem, give me: the specific file or script causing it, the impact on INP, and the one-line fix.

Format the output as a table: Problem | Source | Impact | Fix.

פקודה 5: ביקורת סורקי AI + נתונים מובנים

Check [URL] for AI search and AI crawler readiness:

1. Crawl robots.txt at the domain root. List all rules that mention these user-agents: GPTBot, ClaudeBot, PerplexityBot, Google-Extended, OAI-SearchBot, Amazonbot, Bytespider. If any are blocked, flag it.
2. Extract all JSON-LD blocks from the page. Validate each against Schema.org types. Report which types are present and whether they are complete (all required properties filled).
3. Check if /llms.txt exists at the domain root. If it does, report its content summary. If it does not, note that as a missing AI discovery asset.
4. Check if the page has a clear, self-contained answer (2-4 sentences) to its main topic within the first 200 words of body text.
5. Score the page on AI readiness: 0-100. Deduct points for: missing structured data (-30), blocked AI crawlers (-20 per crawler), no llms.txt (-15), no clear answer block (-20), headings not descriptive (-15).

שאלות נפוצות

ש: האם אני עדיין יכול להשתמש באתר מובייל נפרד (m.example.com)? טכנית כן, אבל Google ממליצה על עיצוב רספונסיבי. כתובות URL נפרדות למובייל מוסיפות מורכבות: עליכם לתחזק תוכן, תגיות canonical ו-hreflang זהות על פני שתי קבוצות URL. אם משהו יוצא מסנכרון, Google מאנדקסת את הגרסה שאותה סרקה לאחרונה. עיצוב רספונסיבי מבטל סיכון זה לחלוטין.

ש: מה אם האתר שלי הוא דסקטופ בלבד — אין גרסת מובייל בכלל? אם Googlebot Smartphone אינו יכול לגשת לתוכן שלכם ולעבד אותו, תוכן זה לא יאונדקס. נקודה. אתר דסקטופ בלבד ב-2026 הוא למעשה בלתי נראה ל-Google. אם אתם במצב זה, מעבר לתבנית רספונסיבית הוא המשימה בעדיפות הגבוהה ביותר שלכם.

ש: האם אני צריך לדאוג לגבי גדלי טאבלטים? Googlebot סורק כסמארטפון, לא כטאבלט. התמקדו בתצוגת הסמארטפון. עם זאת, משתמשי טאבלט הם משתמשים אמיתיים — ודאו שהעיצוב הרספונסיבי שלכם לא נשבר ברוחבים בינוניים (768-1024px).

ש: איך אני יודע אם האתר שלי כבר עבר את מעבר ה-Mobile-First? פתחו את Google Search Console ← Settings ← בדקו את סעיף "About" עבור "Indexing crawler: Googlebot smartphone." אם כתוב כך, אתם באינדוקס Mobile-First. כמעט כל אתר נמצא כך כיום.

ש: האם Google עדיין סורקת את האתר שלי עם user-agent דסקטופ למשהו? כן. Google סורקת לעיתים עם user-agent דסקטופ לבדיקות ספציפיות (אימות קשרים, עיבוד מחדש של נתונים מובנים מסוימים). אל תדאגו אם אתם רואים Googlebot דסקטופ בלוגים שלכם. ביקורים אלה אינם אומרים שהאתר שלכם באינדוקס דסקטופ-ראשון.

ש: האם תיקון בעיות Mobile-First ישפר את הנראות שלי ב-AI Overviews? תיקוני אינדוקס Mobile-First משפרים את הבסיס. אם תוכן המובייל, הנתונים המובנים ומהירות הדף שלכם כולם איתנים, התוכן שלכם זכאי להיות מצוטט — אבל מערכות ה-AI של Google עדיין בוחרות מה לצטט על סמך רלוונטיות, סמכות ואיכות תשובה. תיקון בעיות Mobile-First מסיר מחסום; הוא אינו מבטיח הכללה ב-AI.

מחבר: ג'וליאן מרסר, מומחה SEO טכני עם 14 שנות ניסיון ב-Auspia. ג'וליאן כותב על יכולת סריקה, עיבוד, schema, ארכיטקטורת אתרים והיסודות הטכניים שהופכים תוכן לניתן לגילוי על ידי מנועי חיפוש ומערכות AI.