كيف تتحقق من التوافق بعد إيقاف Google Mobile-Friendly Test؟

أوقفت Google في ديسمبر 2023 كلاً من google mobile friendly test وتقرير «قابلية الاستخدام على الأجهزة الجوّالة» في Search Console. واختفاء نقطة الدخول السابقة التي كانت تتيح «فحصاً واحداً لتحديد ما إذا كانت الصفحة مناسبة للأجهزة الجوّالة» لا يعني أن التوافق مع الأجهزة الجوّالة لم يعد يؤثر في الفهرسة والترتيب؛ فما زالت Google تستخدم بشكل رئيسي Smartphone Googlebot للزحف إلى صفحات الويب، وتعتمد محتوى إصدار الأجهزة الجوّالة كأساس للفهرسة والتقييم.

ما يحتاج فعلاً إلى بديل ليس علامة «تم الاجتياز» الخضراء، بل ثلاثة أنواع من التحقق: هل تستطيع Google الزحف إلى صفحة الجوّال وعرضها؛ وهل يمكن للمستخدمين استخدامها بشكل طبيعي عبر شبكات الهواتف الفعلية؛ وهل تؤثر سرعة الصفحة واستقرار التخطيط سلباً في التجربة. لا يمكن لأداة واحدة تغطية هذه الأمور الثلاثة، والطريقة الأكثر موثوقية هي الجمع بين فحص URL وPageSpeed Insights والتحقق على أجهزة فعلية.

ابدأ بفحص URL للتأكد: هل ترى Google الصفحة بشكل سليم؟

ادخل إلى «فحص عنوان URL» في Google Search Console، وأدخل عنوان URL كاملاً، مع إعطاء الأولوية لعرض الإصدار المفهرس. ما ينبغي التحقق منه هنا ليس ما إذا كانت الصفحة تُفتح على جهاز الكمبيوتر الخاص بك، بل ما إذا كانت الصفحة التي زحفت إليها Google مؤخراً قابلة للفهرسة، وما إذا تم اختيار الصفحة الأساسية المتوقعة، وما إذا كان الزحف يتم باستخدام Smartphone Googlebot.

إذا عُدّلت الصفحة للتو ولم يُعَد الزحف إليها بعد، أو إذا اشتبهت في أن ما تقرؤه Google يختلف عما يظهر في المتصفح، فيمكن استخدام «اختبار عنوان URL الفعلي». ركّز على نتائج الزحف والعرض: فإذا ظهرت مناطق فارغة في لقطة الشاشة، أو غاب المحتوى الرئيسي، أو حجبت النوافذ المنبثقة الصفحة، أو اختل التنسيق، أو ظهرت أخطاء، فالمشكلة لا تكون عادة في «حجم الشاشة»، بل في تحميل الموارد أو العرض من الواجهة الأمامية أو قيود الوصول.

• الاعتماد على JavaScript: إذا كان المحتوى الرئيسي في الجزء الظاهر أولاً، أو مواصفات المنتج، أو محتوى تبديل اللغة يعتمد كلياً على التحميل غير المتزامن عبر البرامج النصية، فيجب التأكد من أن Google تستطيع بالفعل الحصول على هذا المحتوى بعد العرض.
• إمكانية الوصول إلى الموارد: إذا تم حظر ملفات CSS أو JavaScript أو CDN للصور أو ملفات الخطوط بواسطة robots.txt أو WAF أو قيود المناطق أو التحقق من تسجيل الدخول، فسيحصل Googlebot على صفحة غير مكتملة.
• اتساق التصميم المتجاوب: لا ينبغي أن يفقد إصدار سطح المكتب أو إصدار الجوّال معلومات المنتج الأساسية أو النص الرئيسي أو الروابط الداخلية أو البيانات المنظمة بسبب إخفائها عبر CSS.
• رموز الحالة غير الطبيعية: إن إعادة توجيه زيارات الجوّال بشكل خاطئ، أو إرجاع 4xx/5xx، أو توجيهها إلى صفحات غير ذات صلة، كلها تؤثر في الزحف الطبيعي.

يصلح فحص URL للإجابة عن سؤال «هل يستطيع محرك البحث رؤية الصفحة؟»، لكنه ليس أداة لاختبار السرعة، ولا يمكنه أن يحل محل اختبار تفاعل المستخدم. والنتيجة الطبيعية للفحص تعني فقط عدم وجود عائق واضح في مسار الفهرسة.

استخدم PageSpeed Insights لاكتشاف مشكلات أداء الجوّال والتخطيط

ينبغي استخدام PageSpeed Insights ‏(PSI) كنقطة دخول للفحص اليومي. بعد إدخال عنوان الموقع، انتبه إلى التمييز بين «بيانات المستخدمين الفعلية» وبيانات مختبر Lighthouse. تأتي الأولى من مجموعة بيانات تجربة مستخدمي Chrome التي تستوفي الشروط، وتعكس تجربة الزيارات الموجودة؛ أما الثانية فتُشغَّل في بيئة محاكاة للجوّال، وهي مناسبة لتحديد مشكلات الأداء القابلة لإعادة الإنتاج في الصفحة الحالية.

ينبغي على الجوّال بشكل خاص الاهتمام بثلاثة من Core Web Vitals: يعكس LCP سرعة ظهور المحتوى الرئيسي، ويعكس INP استجابة التفاعلات مثل النقر وفتح القوائم وإرسال النماذج، ويعكس CLS ما إذا كانت العناصر تتحرك أثناء تحميل الصفحة. وهي ليست كل ما يتعلق بـ«التوافق مع الجوّال»، لكنها غالباً ما تكشف المشكلات التي تؤثر في الاستفسارات والتصفح، مثل الصور الكبيرة غير المضغوطة في الجزء الظاهر أولاً، وكثرة برامج التتبع النصية التابعة لجهات خارجية، ولافتات Cookie التي تضغط المحتوى، والصور والمحتوى المضمّن الذي لم تُحجز له أبعاد مسبقاً.

ينبغي تقييم توصيات التشخيص في PSI وفقاً لوظائف الصفحة الفعلية، ولا يُنصح بالسعي الآلي إلى الحصول على درجة كاملة. فالمواقع التجارية الخارجية غالباً ما تتضمن برامج نصية متعددة اللغات، وأدوات خدمة العملاء، والتحقق من النماذج، والخرائط، ومقاطع الفيديو، وجميعها تزيد تكلفة التحميل. والترتيب الأكثر قيمة للمعالجة هو: ضمان إتاحة المحتوى الأساسي في الجزء الظاهر أولاً ومدخل الاستفسار أولاً، ثم ضغط الصور وتأجيل البرامج النصية غير الأساسية، وأخيراً تقييم ما إذا كان ينبغي إزالة المكونات غير الضرورية التابعة لجهات خارجية.

لا يُستخدم وضع الأجهزة في المتصفح إلا للفحص الأولي، ولا يزال الجهاز الفعلي ضرورياً

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

بالنسبة إلى الصفحات التي تتضمن استفسارات أو طلبات أو تنزيل مواد، ينبغي إجراء اختبار كامل للمسار على متصفحات الهواتف الشائعة على الأقل: الدخول من صفحة الهبوط في نتائج البحث، وتبديل اللغة، وفتح تفاصيل المنتج، والنقر على WhatsApp أو البريد الإلكتروني أو النموذج، ثم التأكد بعد الإرسال من أن رسالة النجاح وإشعار البريد الإلكتروني يعملان بشكل طبيعي. كثير من الصفحات تبدو «متوافقة» بصرياً، لكن حقل إدخال رمز الدولة لا يفتح لوحة المفاتيح الرقمية، أو يُحجب رمز التحقق بواسطة زر عائم، أو يفشل تحميل المرفقات؛ وهذه المشكلات لا يستطيع mobile friendly test السابق التعرف عليها تلقائياً.

لا تُخطئ باعتبار «التصميم المتجاوب» دليلاً على «صلاحية إصدار الجوّال»

يعالج CSS المتجاوب مشكلة تغيّر التخطيط مع الشاشة، لكنه لا يعالج تجربة الجوّال تلقائياً. وتشمل المخاطر الشائعة: بطء تحميل الجزء الظاهر أولاً بسبب تصغير صور سطح المكتب الكبيرة مباشرة؛ وصعوبة قراءة جداول مواصفات المنتج على الهاتف؛ وعمق مستويات القوائم؛ وتسبّب الخطوط الصغيرة والروابط الكثيفة في نقرات خاطئة؛ وتغطية النوافذ المنبثقة أو الإعلانات للمحتوى الرئيسي؛ والإبقاء على الكثير من الرسوم المتحركة ومقاطع الفيديو ذات التشغيل التلقائي على الجوّال.

بالنسبة إلى الصفحات التي تعتمد على الزيارات العضوية من Google، ينبغي أيضاً التحقق من اتساق إشارات المحتوى بين إصدار الجوّال وإصدار سطح المكتب. فإذا حُذفت طرازات المنتجات، ووصف التطبيقات، وFAQ، ومسارات التنقل، وروابط المنتجات ذات الصلة من إصدار الجوّال من أجل «البساطة»، فستقل كذلك المعلومات التي يمكن لـ Google قراءتها عند إنشاء الفهرس باستخدام إصدار الجوّال. والطريقة الصحيحة ليست إخفاء المعلومات ببساطة، بل تحسين أسلوب القراءة من خلال الأقسام القابلة للطي، والتنقل بالروابط المرسِية، والفقرات القصيرة، والجداول القابلة للتمرير أفقياً، مع الاحتفاظ بالمحتوى الأساسي القابل للزحف.

أدرج الفحص ضمن عملية النشر بدلاً من المعالجة بعد ظهور مشكلات الفهرسة

بعد كل تغيير للقالب، أو تعديل للتنقل، أو دمج لبرامج تسويقية نصية، أو إضافة صفحات متعددة اللغات، أو ضبط لـ CDN، ينبغي إجراء فحص عيّني للصفحة الرئيسية وصفحات المنتجات الأساسية وصفحات المحتوى وصفحات هبوط النماذج. ابدأ بتأكيد التخطيط في وضع الأجهزة بالمتصفح، ثم استخدم PSI لعرض أداء الجوّال وانزياح التخطيط، وأخيراً أجرِ اختبار عنوان URL الفعلي لعناوين URL المهمة من خلال Search Console. وإذا كانت الصفحة مفهرسة بالفعل لكن الزيارات أو مرات الظهور غير طبيعية، فحدّد نطاق المشكلة بالاستناد أيضاً إلى حالة «فهرسة الصفحات» في Search Console ووقت الزحف ومعلومات الصفحة الأساسية.

بعد إيقاف google mobile friendly test، تحوّل عمل الفحص من «نجاح/فشل» لمرة واحدة إلى تحقق مستمر. ومن منظور التنفيذ التشغيلي، ليس الأهم البحث عن زر بديل مطابق تماماً، بل التمييز بين ثلاثة أنواع من المشكلات: العرض والأداء ومسار التحويل؛ فإذا كانت Google لا ترى الصفحة، فابدأ بمعالجة الزحف والموارد؛ وإذا كانت الصفحة بطيئة الفتح، فابدأ بمعالجة الجزء الظاهر أولاً والبرامج النصية؛ وإذا لم يتمكن المستخدم من إكمال الإجراء، فارجع إلى إجراءات الاختبار على الجهاز الفعلي لإصلاحها بنداً بنداً.