دروس في تحسين محركات البحث من إصلاح موقعنا

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

الموقع في فقرة واحدة

mythex.ai تطبيق صفحة واحدة نُنشئ له نسخاً مُعدّة مسبقاً وقت البناء: سكربت يمر على كل مسار، ويكتب ملف HTML ثابتاً لكل منها، ويحقن عنوان الصفحة ووصفها وبيانات البنية المنظمة (كتلة JSON-LD التي تخبر محركات البحث بما هي الصفحة، انظر ما هي البيانات المنظمة). معظم ما يلي يعيش في خطوة التحضير المسبق هذه، لأنها HTML الذي يقرؤه الزاحف فعلاً.

1. كانت كل صفحة تدّعي أنها صفحة الأسئلة الشائعة

العَرَض. كان قالب HTML لدينا يحمل كتلة FAQPage على مستوى الموقع في بيانات البنية المنظمة، وعنوانها يشير إلى /faq. ثم كانت خطوة التحضير المسبق تضيف FAQPage الخاصة بكل صفحة فوقها. فكانت كل صفحة في الموقع تُرسل اثنتين، وكانت سياسة الخصوصية تخبر Google بأنها صفحة الأسئلة الشائعة.

لماذا يهم. تتوقع Google وجود FAQPage واحدة كحدّ أقصى لكل صفحة. والثانية التي تشير إلى مكان آخر هي من النوع الذي يُخفّض تقدير العلامات الخاصة بالصفحة، لا مجرد يتجاهلها.

الإصلاح. اختفت الكتلة العامة. صار كل ما يخص الأسئلة الشائعة في كل صفحة يأتي من مكان واحد، بما في ذلك /faq نفسها، وهي تبنيه من القائمة الكاملة للأسئلة. الصفحات التي ليس لها أسئلة شائعة لا تعلن عن أي منها، وهذه هي الإجابة الصادقة. والتحضير المسبق يفشل البناء إذا احتوت أي صفحة مرة أخرى على أكثر من FAQPage واحدة. القاعدة التي تعيش في ذاكرة شخص ما تُكسر، أما القاعدة التي يفرضها البناء فلا.

2. استخدمت Google الصورة الخطأ لنا

العَرَض. في نتائج البحث، كانت الصورة المصغّرة لـ Mythex هي الوهج النابض الناعم خلف البطل في الصفحة الرئيسية، وهي صورة خلفية زخرفية، بدلاً من بطاقة المشاركة الخاصة بنا.

لماذا حدث ذلك. لم نخبر Google أي صورة تمثل الصفحة، فاختارت صورة من التي وجدتها.

الإصلاح. وجهان لنفس المشكلة:

• قل أي صورة هي للصفحة. صارت الصفحة الرئيسية تملك عقدة WebPage تشير عبر primaryImageOfPage إلى بطاقة المشاركة، وكل بيانات منظمة لصفحة محضّرة مسبقاً تحمل صورتها الخاصة (صورة المشاركة للصفحة، أو الصورة الافتراضية).
• أخفِ الزخرفة. صارت صور الخلفية ممنوعة في robots.txt وتُقدَّم برأس noindex, noimageindex، فتبقى خارج بحث الصور والصور المصغّرة.

3. كانت محركات البحث تعرف شعارنا فقط

كانت بيانات Organization لدينا تحتوي على اسم وشعار وبعض روابط التواصل الاجتماعي، أي علامة تجارية فقط، ولا شيء آخر. تبني محركات البحث لوحة المعرفة للشركة من حقائق شبيهة بالسجلات الرسمية، فأضفنا تلك المأخوذة من رخصة التجارة لدينا: الاسم القانوني، وتاريخ التأسيس، والمؤسس، والعنوان المسجّل. تعمدنا ترك رقم الهاتف خارجاً.

4. كانت صفحات القوالب تجيب عن السؤال الخطأ

العَرَض. أظهرت Search Console ثلاث صفحات قوالب تحصد ظهورات دون أي نقرات. ظهرت واحدة لعبارة «content strategist portfolio» ومتغيراتها، وأخرى لعبارة «best italian restaurant website design»، وثالثة لمجموعة حول «agile board»، ونصف هذه العبارات كان يتضمن كلمة «free». تراوحت المواقع بين منتصف العشرينات والخمسينات.

السبب. كانت كل صفحة تجيب عن سؤال مختلف عن السؤال المطروح. من أراد أن يرى كيف يبدو تصميم مطعم إيطالي جيد، كان يصل إلى صفحة تبيع له أداة بناء.

الإصلاح. لكل صفحة من الثلاث صار لها قسم مكتوب للبحث لا للمنتج، وعنوان ووصف بالكلمات التي يكتبها الناس، وأسئلة شائعة تستحق العلامات التي كانت تُصدرها أصلاً.

أصلح الالتزام نفسه مشكلة أهدأ. كانت كتلة «القوالب ذات الصلة» تأخذ أول أربعة قوالب في الفئة، فكانت كل قوالب البورتفوليو تشير إلى نفس الأربعة بورتفوليوهات، ولم تكن بقية الفئة تملك أي روابط داخلية. استبدلناها بحلقة مرتبة حسب الفئة الفرعية: تحصل كل صفحة قالب الآن على أربعة روابط داخلة وأربعة خارجة بالضبط. كما أن HTML المحضّر مسبقاً يطبع هذه الروابط الآن، بينما كانت من قبل موجودة فقط بعد تشغيل JavaScript، وهو ما قد لا يفعله الزاحف أبداً.

5. إخبار Bing بالصفحات الجديدة لحظة نشرها

تتجاهل Google بروتوكول IndexNow، وهو بروتوكول لإرسال إشعار لمحركات البحث عند تغيّر أي رابط. أما Bing وYandex وSeznam فتستخدمه، وفهرس Bing هو ما يقرؤه بحث ChatGPT. ومنصة لبناء التطبيقات بالذكاء الاصطناعي لا تستطيع مساعدات الذكاء الاصطناعي العثور عليها هي نوع خاص من الفشل.

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

تفصيلتان جعلتا ذلك ينجح:

• التقط اللقطة قبل النشر. يجب التقاط خط الأساس قبل أن يُطلق البناء الجديد. بعد ذلك تكون الخريطة «الحية» هي الجديدة بالفعل، فتعود كل الفروقات فارغة.
• الصفحات الجديدة فقط، في الوقت الحالي. خريطة موقعنا لا تحمل تواريخ lastmod، لذلك يعلن السكربت عن الصفحات الجديدة لا عن إعادة الكتابة. فلو وسمنا كل رابط بتاريخ البناء، لوُسم الموقع كله بأنه متغير في كل نشر، وهو بالضبط النوع من الإزعاج الذي كنا نتفاداه.

يعمل السكربت على عمليات النشر الإنتاجية فقط، ولا يُفشل البناء أبداً: بحلول وقت تشغيله يكون الموقع منشوراً بالفعل، ولا يستحق إشعار محرك البحث أن يُحمّر النشر.

6. حافتنا قالت «غير موجود»

عندما أطلقنا صفحات /ai (المزيد عنها في صفحة هبوط لكل نوع من الأعمال)، كانت بيئة الاختبار تعرض «Not found» لكل منها، بينما كانت الاستضافة الثابتة تقدمها بشكل سليم.

الخدمة التي تقف أمام نطاقات التسويق لدينا تمرر فقط قائمة مسموحة من المسارات، وأي مسار آخر يحصل على خطأ 404 صارم. كان /ai جديداً ولم يكن في القائمة. أضفنا /ai و/ai/* مع اختبار يؤكد أنهما يمرّان. خطأ صغير، لكنه من النوع الذي يجعل قسماً جديداً غير مرئي لمحركات البحث دون أن يلاحظه أحد.

ما الذي استخلصناه

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

إذا كنت تفعل الشيء نفسه لموقع بنيته أنت، فإن أدلتنا عن تحسين محركات البحث للمواقع المبنية بالذكاء الاصطناعي وإعداد Google Search Console تغطي الأساسيات.