تحسين محركات البحث لجافا سكريبت: تأكد من بقاء الروابط بعد العرض
تعرض جوجل جافا سكريبت باستخدام متصفح Chromium دائم التحديث. المشكلة نادرًا ما تكون في عملية العرض نفسها، بل في الروابط التي لا تتحول إلى عناصر <a>، والصفحات التي تعتمد على حالة لا يمتلكها زاحف الروابط.
فريق أبحاث ArchiLinks ·
ما يراه زاحف الروابط
يستخدم Googlebot متصفح Chromium دائم التحديث منذ مايو 2019. وهذا حسم الجدل بشأن قدرته على تشغيل جافا سكريبت الحديثة.
المخاطر العملية هي مخاطر قديمة: يحدث العرض بعد الزحف وقد يتأخر، والمحتوى خلف النقرات أو تسجيل الدخول لا يظهر أبدًا، والروابط المبنية من معالج onclick على عنصر div ليست روابط فعلية. قبل فحص الروابط الخلفية لصفحات الموقع التي نقلت مؤخرًا إلى واجهة أمامية مبنية على React، تأكد من أن تلك الصفحات تعرض محتواها في الاستجابة الخام أو في HTML المعروض.
SSR، SSG، CSR: ماذا يتغير بالنسبة للروابط
| النهج | المحتوى في الاستجابة الأولى | الروابط الداخلية كعناصر <a> | مناسب لـ |
|---|---|---|---|
| SSR (Next.js، Nuxt) | نعم | نعم، إذا استخدمت عناصر <a> حقيقية | الصفحات العامة ذات البيانات المتغيرة |
| SSG أو التقديم المسبق | نعم | نعم | الوثائق، المدونات، صفحات التسويق |
| تطبيق صفحة واحدة يعتمد على CSR | لا، غلاف فارغ | فقط بعد العرض | لوحات التحكم خلف تسجيل الدخول |
| هجين (صفحة رئيسية SSR، تطبيق CSR) | لكل مسار | لكل مسار | معظم المنتجات ذات الجانب العام |
اختبار 1: HTML الخام مقابل HTML المعروض
إذا ظهرت الروابط الرئيسية في الاستجابة الأولى، فإن السؤال يكون قد حُسم. إذا لم يكن كذلك، قارن مع العرض باستخدام متصفح بدون واجهة (headless).
# raw response: are the links there?
curl -s https://new-shop.com/guides/ | grep -o '<a [^>]*href="[^"]*"' | head -20
# rendered DOM with headless Chrome
chrome --headless --dump-dom https://new-shop.com/guides/ | grep -c '<a '
من أين تأتي الروابط الخارجية
خطأ في العرض يخفي محتواك. لا يمحى الروابط التي منحك إياها المواقع الأخرى بالفعل.
بعد الانتقال إلى Next.js أو Vite أو نظام إدارة محتوى لا يعتمد على الواجهة (headless CMS)، شغل toppages للمضيف واختبر أكثر 20 عنوان URL ارتباطًا من حيث الحالة، والعنوان المفضل، والمحتوى المرئي. افعل ذلك أولاً. إذا كانت الصفحة التي تحتوي على 40 نطاقًا مرجعيًا تُرجع غلافًا فارغًا أو خطأ 404 من جانب العميل، فأصلحها قبل أي شيء آخر، لأن هذا هو المكان الذي تتراكم فيه سلطتك. يوضح صفحة حقوق الروابط الداخلية مقابل الخارجية كيفية مقارنة هذه القائمة بروابطك الداخلية، ويضع قائمة التحقق من الهجرة الاختبار ضمن خطة الإطلاق.
أطر العمل أقل أهمية من الانضباط. يمكن لـ Express مع محرك قوالب، أو سمة WordPress، أو مسار تطبيق Next.js أن تقدم روابط قابلة للحجز. ويمكن لكل منها أيضًا أن يفشل إذا أرسل الفريق عناصر <a> لا توجد إلا بعد النقر.
قائمة التحقق من الروابط والعرض
- يستخدم التنقل والترقيم
<a href>، وليس معالجات النقر على عناصر أخرى. - يعيد كل مسار رمز حالة حقيقي. يجب أن تُرجع شاشات الخطأ 404 الناعم (Soft 404) رمز 404.
- يجب أن يتطابق
noindexأو العنوان المفضل (canonical) الذي تُحقنه جافا سكريبت مع الموجود في استجابة الخادم. - المحتوى الاحتياطي في الاستجابة الأولى هو الصفحة الحقيقية، وليس مؤشر التحميل الذي قد تقوم Google بفهرسته.
- رمز المصادقة لا يحول زاحفي الروابط عن المسارات العامة.
- ملفات CSS وJS اللازمة للعرض غير محظورة في ملف robots.txt.
- يستخدم التحميل الكسول IntersectionObserver أو سمات التحميل الأصلية، وليس أحداث التمرير.
قراءة أدلة Search Console
تجيب Search Console على معظم أسئلة العرض إذا طلبت التقرير الصحيح. استخدم فحص URL، ثم عرض الصفحة المزاحة.
قارن ثلاثة أشياء: HTML الذي جلبته Google، لقطة الشاشة، وموارد الصفحة التي فشلت في التحميل. الصفحة التي تبدو مكتملة في متصفحك لكنها فارغة في لقطة الشاشة تكون عادةً محجوبة بسبب خطأ في السكربت أو مورد غير مسموح به، والحل يكمن في عملية البناء (build) الخاصة بك، وليس في محتواك.
تذكر التأخير. التغيير الذي تنشره اليوم سيظهر في أداة الفحص فقط بعد أن تعيد Google زحف الرابط، وقد يستغرق ذلك أيامًا.
متى يكون SSR ذا قيمة
الصفحات العامة التي يجب أن تحقق ترتيبًا: نعم. لوحات التحكم: لا.
إذا كان المسار يجب أن يجذب حركة مرور عضوية، قدم المحتوى في الاستجابة الأولى. إذا كان خلف تسجيل الدخول، تجنب التعقيد. اختر لكل مسار وليس للمشروع بأكمله، ووثّق القرار حتى لا يلغيه المطوّر التالي.
- استخدم اختبار النتائج الغنية وفحص URL لمقارنة المخرجات المُعرضة.
- اختبر باستخدام اختبار Live في Search Console بعد كل تحديث للإطار.
هل يتطلب الأمر عرض الخادم، أم أن العرض المسبق كافٍ؟
عرض الخادم اختياري. إنه وسيلة لجعل الاستجابة الأولى تحمل ما يحتاجه الزاحف. العديد من المواقع العامة تصل إلى ذلك باستخدام العرض المسبق، أو بناء ثابت، أو عرض الخادم للصفحات المهمة، وترك الأجزاء التي تتطلب تسجيل الدخول كما هي.
لنفترض أن صفحات المنتجات والمستندات عامة، بينما لوحة التحكم خلف تسجيل الدخول. قم بالعرض المسبق للمجموعة الأولى. اترك لوحة التحكم تعمل على جانب العميل. ثم تحمل الصفحات العامة روابطها في الاستجابة الأولى، ويمكن أن تظل لوحة التحكم معقدة بقدر ما تحتاج.
العرض المسبق للصفحة الرئيسية فقط
يحل العرض المسبق للصفحة الرئيسية مشكلة الزحف الأول، لكنه يترك كل مسار آخر ينتظر المتصفح. إذا كانت الصفحة الرئيسية تربط بصفحات فئات يتم عرضها على جانب العميل، فإن الروابط على تلك الصفحات لا تزال تعتمد على العرض. تحقق من كل قالب تملكه، وليس فقط البوابة الأمامية.
احتفظ بقائمة قصيرة من المسارات العامة مع طريقة العرض الخاصة بها. ستظهر القائمة الفجوات بشكل أسرع من تقرير الزحف.
هل يغير عرض الخادم الرؤية المحلية
يمكن أن يغير عرض الخادم من سرعة ظهور المحتوى الأول، ويشعر القراء بذلك. لا يجعل الصفحة ذات صلة باستعلام محلي بمفرده. تأتي هذه الإشارات من محتوى الصفحة، وتفاصيل العمل، والروابط التي تشير إليها.
عامل العرض كوسيلة لجعل هذه الإشارات قابلة للقراءة من قبل الزاحف، وقيس الروابط بشكل منفصل باستخدام API.
تطبيقات Vite و React التي تقدم غلافًا واحدًا
بناء Vite يقدم غلاف HTML واحدًا لكل مسار يضع كل العمل على جانب العميل. يمكن أن لا تزال مثل هذه التطبيقات تحقق ترتيبًا لبعض الاستعلامات، لكن كل مسار عام يحتاج إلى خطة: قم بالعرض المسبق له، أو عرضه على الخادم، أو اقبل الخسارة ووثّق ذلك.
قبل أن تتحقق من الروابط الخلفية لمسارات الموقع بعد إعادة البناء، قرر كيف يحصل كل مسار عام على محتواه. وإلا فإن بيانات الروابط ستظهر روابط خارجية تهبط على صفحات فارغة.
اختبار ما إذا كان المسار يعرض روابطه
اختباران يجيبان عن معظم الأسئلة. الاستجابة الخام تظهر ما يحصل عليه الزاحف قبل تشغيل أي سكريبت. DOM المعروض يظهر ما يبنيه المتصفح بعد ذلك. الرابط الذي يظهر فقط في الثاني لا يزال رابطًا، لكنه يعتمد على نجاح العرض.
قراءة الاختبار المباشر في Search Console
شغّل الاختبار المباشر من فحص URL على مسار واحد في كل مرة. انظر إلى HTML المعروض، ثم إلى قائمة الموارد التي فشلت في التحميل. يمكن أن يؤدي سكريبت محظور إلى إزالة كتلة تنقل كاملة، وتبدو الصفحة رقيقة دون إظهار أي خطأ مرئي.
كرر الاختبار بعد تحديث الإطار، لأن الافتراضي الجديد يمكن أن يغير ما إذا كانت الروابط تُعرض قبل أو بعد تشغيل سكريبت. يغطي دليل الصفحات غير المفهرسة ما يجب فعله عندما تبقى الصفحة المعروضة خارج الفهرسة.
عندما يعرض مسارًا ولكن المحتوى هو مؤشر تحميل
يُعدّ التحوّل الاحتياطي في الاستجابة الأولى أكثر أهمية مما يتوقعه معظم الفرق. فوجود مؤشر تحميل أو حاوية فارغة يعني أن الصفحة لا تحتوي على نص يمكن للزاحف قراءته في تلك اللحظة. ضع العنوان، والمقدمة، والروابط الرئيسية في الاستجابة الأولى، حتى لو كانت القائمة التفصيلية تُحمّل لاحقاً.
يمكن أن يكون التحوّل الاحتياطي، الذي يمثل الصفحة الحقيقية، بسيطاً. وظيفته الوحيدة هي احتواء المحتوى حتى وصول باقي البيانات.
نقل موقع يعتمد على واجهة المستخدم دون فقدان روابطه
قائمة المسارات التي تحتوي على روابط خارجية
شغّل أداة toppages على المضيف (host) وسجّل أفضل 50 عنوان URL. اختبر تلك المسارات أولاً، قبل إجراء التغييرات في الكود، لتعرف ما يجب أن تحافظ عليه عملية إعادة البناء.
قارنة المخرجات الخام مع المخرجات بعد المعالجة (Rendered)
بالنسبة لكل مسار، تحقق من كود HTML الخام ومن الـ DOM المعالج في الإصدار القديم والجديد. لاحظ أي رابط موجود في أحدهما وليس في الآخر.
استبدال معالجات النقر بوسوم الروابط (Anchors)
حوّل التنقل إلى روابط حقيقية ذات عنوان صحيح. يمكن تأجيل تحسينات السرعة إلى مرحلة تطوير (Sprint)، بينما يكلفك الرابط المفقود مسار الصفحة داخل الموقع.
كرر الاختبار بعد الإطلاق
بعد أسبوع من الإطلاق، شغّل الاختبار على الموقع الحي لنفس المسارات وقارن النتائج مع النتائج السابقة. تُظهر الفروقات أين غيرت عملية إعادة البناء المخرجات.
رموز الحالة وإعادة التوجيه في تطبيق يعتمد على واجهة المستخدم
غالباً ما يعرض تطبيق الصفحة الواحدة شاشة "الصفحة غير موجودة" بينما يُعيد الخادم رمز الحالة 200. يمكن لـ Google التعامل مع مثل هذه الصفحة على أنها خطأ 404 ناعم (Soft 404)، مما يجعل الروابط الخارجية المؤدية إلى عنوان URL المفقود أقل فائدة لك. الحل يكمن في الخادم.
مسارات غير معروفة تُعيد رمز الحالة 200
أعد رمز 404 حقيقي من الخادم لأي مسار غير موجود، واحتفظ بشاشة "الصفحة غير موجودة" داخل التطبيق للزوار الذين يصلون عبر مسار في الواجهة الأمامية. إذا كان هناك بديل، أرسل رمز 301 بدلاً من ذلك.
تحقق من بعض العناوين الوهمية على المضيف الحي بعد كل إصدار. رمز الاستجابة هو ما يجب قراءته، وليس الصفحة التي تراها في المتصفح.
إعادة التوجيه التي تعمل في المتصفح
إعادة التوجيه التي تُفعّل بعد تحميل الصفحة، على سبيل المثال عن طريق قراءة معلمة URL داخل مكون (Component)، هي أمر مختلف عن إعادة التوجيه من الخادم. قد يقوم الزاحف بفهرسة الاستجابة الأولى قبل تنفيذ إعادة التوجيه. إذا كان المسار قد انتقل بشكل دائم، أعد رمز 301 من الخادم واحتفظ بالمعاملات التي تغير المحتوى. يوضح وصفة خريطة إعادة التوجيه كيفية اختبار هذه القواعد.
