فهرسة 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 Overviews من Google في حوالي 47% من عمليات البحث حتى منتصف 2026. عندما تولد أنظمة الذكاء الاصطناعي من Google الإجابات، فإنها تسحب من نفس المحتوى المفهرس على الجوال الذي يستخدمه البحث العادي. كما تصل برامج زحف الذكاء الاصطناعي التابعة لجهات خارجية (GPTBot و ClaudeBot و PerplexityBot) إلى صفحات الجوال الخاصة بك.

إذا كان إصدار الجوال الخاص بك يفتقر إلى البيانات المنظمة أو العناوين الواضحة أو النص الأساسي، فلا يمكن لأنظمة الذكاء الاصطناعي الاستشهاد بك — حتى لو كان إصدار سطح المكتب يحتوي على هذا المحتوى.

التحول 3: فجوات تكافؤ المحتوى لها الآن تأثير قابل للقياس على الترتيب

في عام 2026، تظهر المواقع ذات المحتوى غير المتسق بين الجوال وسطح المكتب انخفاضًا بنسبة 31.2% في ظهور البحث العضوي في المتوسط مقارنة بالمواقع ذات التكافؤ الكامل للمحتوى. أكثر العناصر المفقودة شيوعًا على الجوال: محتوى علامات التبويب المخفية، روابط الشريط الجانبي، ترميز البيانات المنظمة، نصوص alt للصور، وروابط التنقل الداخلية.

كيفية التحقق مما إذا كان موقعك يجتاز (نسخة الدقيقتين)

قبل تشغيل تدقيق كامل، تحقق من هذه الإشارات الثلاث. تستغرق كل واحدة أقل من دقيقة وتخبرك ما إذا كنت بحاجة إلى التعمق أكثر.

الإشارة 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 أو قائمة عناوين URL للجاهزية لفهرسة Mobile-First. يتحقق من تكافؤ المحتوى، Core Web Vitals، البيانات المنظمة، UX الجوال، ووصول برامج زحف الذكاء الاصطناعي.

# تدقيق فهرسة 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. إذا كانت مفقودة أو إذا حددت عرضًا ثابتًا أو عطلت تحجيم المستخدم دون سبب وصول صالح، ضع علامة FAIL.

### 2. تكافؤ المحتوى (النص)
اجلب الصفحة باستخدام وكيل مستخدم سطح المكتب ووكيل مستخدم الجوال (Googlebot Smartphone). قارن محتوى النص المرئي. إذا كانت أي كتلة نصية تزيد عن 50 كلمة موجودة على سطح المكتب ولكن ليس في مصدر HTML للجوال، ضع علامة WARN. إذا كان نص الجسم المهم أو العناوين أو أوصاف المنتج مفقودة، ضع علامة FAIL.

### 3. تكافؤ البيانات المنظمة
استخرج جميع كتل JSON-LD من كلتا عمليتي جلب سطح المكتب والجوال. إذا كان أي نوع schema موجودًا على سطح المكتب ولكنه مفقود من الجوال، ضع علامة FAIL. إذا اختلف محتوى schema بين الإصدارات، ضع علامة WARN.

### 4. تكافؤ علامات Meta
قارن علامات العنوان والوصف التعريفي و canonical و robots و hreflang بين إصداري سطح المكتب والجوال. أي اختلاف هو WARN. فقدان canonical أو تعارض علامة robots هو FAIL.

### 5. الروابط الداخلية والتنقل
احسب عدد علامات `<a href>` للروابط الداخلية في HTML سطح المكتب والجوال. إذا كان إصدار الجوال يحتوي على 20%+ روابط داخلية أقل، ضع علامة WARN. إذا كانت روابط مسار التنقل أو التنقل بالفئة أو روابط التذييل موجودة على سطح المكتب ولكنها مفقودة من الجوال، ضع علامة 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.5 ثانية = WARN، > 4.0 ثانية = FAIL. INP > 200 مللي ثانية = WARN، > 500 مللي ثانية = 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. وصول برامج زحف الذكاء الاصطناعي
تحقق من robots.txt بحثًا عن قواعد تحظر GPTBot أو ClaudeBot أو PerplexityBot أو Google-Extended أو OAI-SearchBot. إذا تم حظر أي برنامج زحف AI، لاحظ ذلك كخيار متعمد. إذا تم السماح لبرامج زحف AI لكن الصفحة لا تحتوي على بيانات منظمة، ضع علامة WARN (تعتمد أنظمة AI على البيانات المنظمة للاستشهادات).

## تنسيق المخرجات

أنتج تقرير Markdown:

```markdown
# تقرير تدقيق Mobile-First
**التاريخ:** YYYY-MM-DD
**عناوين URL المدققة:** 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، بالإضافة إلى قائمة انتظار الإصلاحات ذات الأولوية.

لفحص صفحات متعددة دفعة واحدة، استخدم الأمر التالي مع عناوين URL الخمسة:

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 أو مفاتيح الرؤية) لسلوك الإظهار/الإخفاء بدلاً من حقن المحتوى بـ JavaScript.

البيانات المنظمة المفقودة على الجوال

يجب أن تكون البيانات المنظمة (JSON-LD) موجودة في HTML الجوال. من السهل تفويت هذا إذا كان قالب الجوال أو إصدار AMP يستخدم قالبًا مختلفًا.

كيفية التحقق: افتح صفحة الجوال، اعرض المصدر (Cmd+Option+U)، وابحث عن application/ld+json. ثم افعل الشيء نفسه على سطح المكتب. يجب أن تظهر كتل JSON-LD نفسها في كليهما.

كيفية الإصلاح: تأكد من عرض بياناتك المنظمة من جانب الخادم وتضمينها في نفس استجابة HTML لكل من الجوال وسطح المكتب. إذا كنت تستخدم CMS، فتحقق من أن مكون schema الإضافي أو القالب الخاص بك لا يقوم بتحميل البرامج النصية بشكل مشروط بناءً على اكتشاف الجهاز.

روابط التنقل المحذوفة من قوائم الجوال

غالبًا ما تبسط قوائم الجوال أو تزيل الروابط الموجودة في تنقل سطح المكتب: مسارات التنقل، روابط الفئات، أعمدة التذييل، روابط الشريط الجانبي. تستخدم Google الروابط الداخلية لفهم بنية الموقع وتوزيع PageRank. الروابط المفقودة من الجوال مفقودة من رسم Google البياني.

كيفية التحقق: احسب عدد علامات <a href> في مصدر سطح المكتب مقابل مصدر الجوال. يجب أن يكون للتصميم المتجاوب أعداد متساوية تقريبًا. إذا كان عدد الجوال أقل بنسبة 30%+، فتحقق من الروابط التي اختفت.

كيفية الإصلاح: أضف روابط التنقل المفقودة إلى قائمة الجوال أو قائمة الهامبرغر أو التذييل. أعط الأولوية للروابط إلى صفحات الفئات المهمة والمقالات الرئيسية والصفحات الأم.

الإصلاح #2: INP — مقياس سرعة الجوال الذي تتجاهله معظم المواقع

يقيس Interaction to Next Paint (INP) المدة التي تستغرقها الصفحة للاستجابة بصريًا بعد نقر المستخدم أو ضغطه على مفتاح. العتبة هي 200 ملي ثانية أو أقل.

على عكس FID، الذي كان يقيس فقط تأخير الإدخال للتفاعل الأول، يقيس INP كل تفاعل ويبلغ عن أسوأ تفاعل. وهذا يجعله اختبارًا أكثر صرامة.

ما يقتل INP على الجوال

الأسباب الأكثر شيوعًا، بالترتيب:

1. JavaScript ثقيل يعمل على المسار الرئيسي. الحزم الكبيرة ومكونات React/Vue غير المحسنة وبرامج التتبع النصية تمنع المتصفح من الاستجابة للنقرات.
2. معالجات النقر التي تقوم بالكثير من العمل قبل تحديث واجهة المستخدم. إذا أدت نقرة إلى استدعاء API وتحديث حالة وتغيير DOM قبل إظهار أي ملاحظات بصرية، يتأثر INP.
3. علامات الطرف الثالث. التحليلات وأدوات الدردشة وشبكات الإعلانات وبرامج التخصيص النصية — خاصة عندما تتنافس علامات متعددة على المسار الرئيسي.

كيفية تشخيص INP

1. افتح PageSpeed Insights، أدخل عنوان URL الخاص بك، ثم انتقل إلى قسم بيانات المستخدمين الحقيقيين (CrUX). قيمة INP ضمن تبويب "Mobile" هي ما تستخدمه Google.
2. في Chrome DevTools، افتح لوحة Performance، اضغط على زر التسجيل (record)، تفاعل مع الصفحة (انقر على الأزرار، افتح القوائم، اكتب في المدخلات)، ثم أوقف التسجيل. ابحث عن المهام الطويلة (محددة باللون الأحمر، 200 ملي ثانية فأكثر). هذه هي مشاكل 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 الطويلة.
  → تقسيم الكود حسب المسار. التحميل الكسول للمكونات أسفل الشاشة.
  → نقل الحوسبة الثقيلة إلى requestIdleCallback() أو Web Worker.

الأولوية 3: جعل معالجات النقر تحدث واجهة المستخدم فورًا.
  → إظهار حالة تحميل أو مؤشر دوار أو زر معطل في أول 50 مللي ثانية.
  → تشغيل العمل الفعلي (استدعاء API، تحديث الحالة) بعد الاستجابة البصرية.

الإصلاح #3: جاهزية برامج زحف الذكاء الاصطناعي (طبقة 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 تزحف إلى موقعي باستخدام وكيل مستخدم سطح المكتب لأي شيء؟ نعم. تزحف Google أحيانًا باستخدام وكيل مستخدم سطح المكتب لفحوصات محددة (التحقق من العلاقة، بعض إعادة معالجة البيانات المنظمة). لا تقلق إذا رأيت Googlebot سطح المكتب في سجلاتك. هذه الزيارات لا تعني أن موقعك يستخدم فهرسة سطح المكتب أولاً.

س: هل سيؤدي إصلاح مشكلات Mobile-First إلى تحسين ظهوري في AI Overviews؟ إصلاحات فهرسة Mobile-First تحسن الأساس. إذا كان محتوى الجوال والبيانات المنظمة وسرعة الصفحة كلها قوية، فإن المحتوى الخاص بك مؤهل للاستشهاد به — لكن أنظمة AI من Google لا تزال تختار ما تستشهد به بناءً على الصلة والمصداقية وجودة الإجابة. إصلاح مشكلات Mobile-First يزيل عائقًا؛ ولا يضمن الإدراج في AI.

المؤلف: جوليان ميرسر، ممارس SEO تقني لمدة 14 عامًا في Auspia. يكتب جوليان عن قابلية الزحف والعرض و schema وهندسة المواقع والأسس التقنية التي تجعل المحتوى قابلاً للاكتشاف من قبل محركات البحث وأنظمة الذكاء الاصطناعي.