التدقيق التقني للسيو (SEO): ما الذي يجب أن يغطيه، وما الذي يجب أن يُظهره التقرير

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

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

ابدأ بالسؤال الصحيح: ما الذي يجب أن يُفهرس؟

قبل تشغيل أي زاحف، ينبغي أن يتفق المدقق معك على الصفحات المهمة: صفحات الخدمات، وصفحات المنتجات أو الفئات، ودراسات الحالة، وصفحات المواقع، ومسارات التواصل وطلب عرض السعر. وكل ما عدا ذلك ثانوي. وهذا مهم لأن Google نفسها تقول إن الفهرسة لا تلزم كل رابط. إذ إن توثيق تقرير فهرسة الصفحات يذكر أن الهدف هو فهرسة النسخة القانونية (canonical) من كل صفحة مهمة، وأن الروابط غير المفهرسة قد تكون سليمة.

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

الفحوصات التي يجب أن يغطيها تدقيق موقع مؤسسي

القائمة أدناه هي الجوهر. وكل بند فيها مبني على توثيق منشور من محركات البحث، لا على نموذج تقييم لدى مزوّد أدوات.

1. الوصول للزحف وملف robots.txt

• هل يحجب robots.txt شيئًا مهمًا، بما في ذلك ملفات CSS وJavaScript التي تحتاجها الصفحة للعرض؟
• هل يُستخدم robots.txt لإخفاء الصفحات عن البحث؟ مقدمة robots.txt من Google صريحة في أنه ليس آلية لإبقاء الصفحة خارج Google؛ فقد يُفهرس الرابط المحجوب إذا ربطت به صفحات أخرى. وتحتاج الصفحات التي يجب أن تبقى خارج البحث إلى noindex أو حماية بكلمة مرور.
• هل تمنع أخطاء الخادم (5xx) أو استجابات 401/403 أو قواعد جدار الحماية الزواحف من الوصول إلى بعض الأقسام؟

2. حالة الفهرسة، من Search Console

ينبغي أن يعتمد التدقيق على تقرير فهرسة الصفحات في Google Search Console، لا على زحف من طرف ثالث فقط. يصنّف هذا التقرير الروابط تحت أسباب مسماة مثل «Crawled – currently not indexed» و«Discovered – currently not indexed» و«Duplicate without user-selected canonical» و«Duplicate, Google chose different canonical than user» و«Alternate page with proper canonical tag» و«Page with redirect» و«Soft 404» و«URL marked ‘noindex’» (Google). والتقرير المفيد يشرح أيًا من هذه الحالات يؤثر في الصفحات المهمة ولماذا. فمثلًا ظهور «Alternate page with proper canonical tag» على رابط مكرر هو عادةً علامة على أن الأمور تعمل كما ينبغي.

3. النسخة القانونية والروابط المكررة

تولّد مواقع الشركات نسخًا مكررة بسهولة: http وhttps، وwww و من دون www، والشرطة المائلة في نهاية الرابط، ومعاملات التتبع، ونسخ الطباعة، والخدمة نفسها المدرجة تحت مسارين في القائمة. وتصف إرشادات Google لتحديد النسخة القانونية إعادة التوجيه و rel=”canonical” بأنهما إشارتان قويتان، وإدراج الرابط في خريطة الموقع بأنه إشارة ضعيفة. كما تحذّر من استخدام robots.txt أو noindex لاختيار النسخة القانونية، ومن تحديد روابط قانونية مختلفة للصفحة نفسها بطرق مختلفة. وينبغي أن يتحقق التدقيق من أن الروابط القانونية والروابط الداخلية وخريطة الموقع كلها تشير إلى النسخة نفسها.

4. إعادة التوجيه وعمليات نقل الموقع السابقة

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

5. النسختان العربية والإنجليزية

هنا تخطئ المواقع ثنائية اللغة في الخليج ومصر أكثر من غيره (ويغطي دليلنا عن هيكل الموقع بالعربية والإنجليزية جانب البناء). وينبغي أن يتحقق التدقيق من:

• روابط منفصلة لكل لغة. Google توصي باستخدام روابط مختلفة لكل نسخة لغوية بدلًا من تبديل اللغة عبر ملف تعريف الارتباط أو إعداد المتصفح، وتنصح بعدم إعادة توجيه المستخدمين تلقائيًا بحسب اللغة أو عنوان IP.
• hreflang صحيحة. بحسب توثيق Google للنسخ المحلية، يجب أن تدرج كل نسخة نفسها وجميع النسخ الأخرى، وإذا لم تشر صفحتان إحداهما إلى الأخرى فستُتجاهل الوسوم. وتستخدم الرموز معيار ISO 639-1 للغة، ومعيار ISO 3166-1 Alpha 2 اختياريًا للمنطقة (مثل ar، ar-SA، en-AE)؛ ولا يصح رمز البلد وحده. x-default يمكن أن يحدد الصفحة الاحتياطية.
• محتوى مترجم فعلًا. تقول Google إن النسخ المحلية لا تُعدّ مكررة إلا إذا ظل المحتوى الرئيسي غير مترجم. وصفحة «عربية» لا يُترجم فيها إلا القائمة والتذييل ويبقى المتن بالإنجليزية مشكلة حقيقية، ونادرًا ما تنبّه إليها الزواحف.
• تُحدَّد اللغة من المحتوى المرئي. تذكر Google أنها لا تستخدم hreflang ولا سمة HTML lang لاكتشاف لغة الصفحة. وما زالت هذه السمات مهمة لإمكانية الوصول ولربط hreflang، لكنها لن تنقذ صفحة نصها المرئي بلغة خاطئة.

6. Core Web Vitals، من بيانات الميدان

تحدد صفحة Core Web Vitals من Google الأهداف: أكبر عنصر محتوى مرئي (LCP) خلال 2.5 ثانية، والتفاعل حتى الرسم التالي (INP) أقل من 200 مللي ثانية، والتحول التراكمي في التخطيط (CLS) أقل من 0.1. وبحسب web.dev، تُقيَّم هذه المقاييس عند المئين 75 من تحميلات الصفحات، مقسّمة إلى جوال وسطح مكتب، وأصبح INP مقياسًا مستقرًا ضمن Core Web Vitals في 2024، بديلًا عن First Input Delay. ويعرض التدقيق الموثوق بيانات المستخدمين الفعليين (الميدان) حيثما وُجدت، ويفصل الجوال عن سطح المكتب، ويحدد القوالب المسببة للمشكلة، مثل فيديو رئيسي كبير الحجم أو مساحة لافتة غير محجوزة، بدلًا من سرد كل رابط على حدة.

7. البيانات المنظمة

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

8. سياسات مكافحة الرسائل المزعجة ومخاطر الأمان

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

9. وصول زواحف البحث بالذكاء الاصطناعي

يستخدم بعض المشترين الآن مساعدات الذكاء الاصطناعي لبحث الموردين، لذا ينبغي أن يذكر التدقيق أي زواحف ذكاء اصطناعي تستطيع الوصول إلى الموقع وهل كان ذلك قرارًا مقصودًا. OpenAI تفصل بين بحث ChatGPT (OAI-SearchBot) وتدريب النماذج (GPTBot)، وتشير Perplexity إلى أن جدار حماية أو إعدادًا لحماية الروبوتات قد يحجب زاحفها حتى لو سمح robots.txt، وهو سبب خفي متكرر في المواقع الواقعة خلف شبكات CDN. Google تذكر أنه لا توجد متطلبات إضافية ولا ملفات نصية خاصة بالذكاء الاصطناعي ولا مخططات إضافية للظهور في AI Overviews أو AI Mode، ولذا فالتدقيق الذي يوصي بها بوصفها شرطًا من Google مخطئ. ويرد جدول الزواحف الكامل وطريقة تتبع الاقتباسات في دليلنا عن كيف تُقتبس في بحث ChatGPT.

10. Bing وIndexNow

يدير Bing فهرسه وأدواته الخاصة، لذا ينبغي أن يتأكد التدقيق من توثيق الموقع في Bing Webmaster Tools مع خريطة موقع مقدّمة. وإذا كان الموقع يستخدم IndexNow، فيجب استضافة ملف المفتاح بشكل صحيح؛ وتشير وثائق البروتوكول إلى أن الروابط المقدّمة تُشارك مع كل المحركات المشاركة، وهي كما يسردها FAQ Amazon وBing وNaver وSeznam.cz وYandex وYep. ولا تظهر Google في القائمة، لذا لا يحل IndexNow محل Search Console.

تصدير أداة أم خطة عمل: كيف تميّز بينهما

درجات الأدوات ليست مقاييس Google. فقد يحصل موقع على درجة ضعيفة في زاحف وأداؤه جيد في البحث، أو على درجة عالية بينما صفحات خدماته الرئيسية مستبعدة بوصفها مكررة. تعامل مع أي درجة بوصفها عَرَضًا يستحق التحقيق، لا هدفًا.

ما الذي يجب أن يُظهره التقرير النهائي

أيًا كان من يكتبه، اطلب تقريرًا بهذه الأجزاء:

1. النطاق والبيانات. أي النطاقات واللغات والنطاقات الفرعية فُحصت، وتاريخ الزحف، وأي خصائص Search Console والتحليلات استُخدمت.
2. الملخص التنفيذي. من خمس إلى عشر ملاحظات بلغة واضحة، لكل منها أثرها على العمل: «صفحات الخدمات العربية غير مفهرسة لأن رابطها القانوني يشير إلى النسخة الإنجليزية»، لا «مشكلات الروابط القانونية: 214».
3. مصفوفة الأولويات. كل مشكلة مقيَّمة بأثرها على الصفحات المهمة وبجهد إصلاحها، مع مسؤول عنها (المطوّر أو فريق المحتوى أو مزوّد الاستضافة).
4. الأدلة. روابط نموذجية، ولقطات شاشة لحالات Search Console، ورموز الاستجابة التي وُجدت.
5. الإصلاحات المحددة. خريطة إعادة التوجيه، ومجموعة hreflang المصححة، وتعديل robots.txt، مكتوبة بحيث يستطيع المطوّر تنفيذها دون تأويل.
6. خطة التحقق. كيف سيُؤكَّد كل إصلاح: فحص الرابط URL Inspection، والتحقق في تقرير فهرسة الصفحات، إعادة زحف، وبيانات ميدانية جديدة بعد تسجيل عدد كافٍ من الزيارات الجديدة.

تنفيذ التدقيق والعمل بنتائجه

لا قيمة للتدقيق إلا إذا تبعته تغييرات، لذا خطّط للعمل بهذا الترتيب:

1. العوائق أولًا: كل ما يمنع زحف الصفحات المهمة أو فهرستها (robots.txt، وnoindex المتبقي من بيئة التجهيز، والروابط القانونية الخاطئة، وإعادة التوجيه المعطلة).
2. اللغة والتكرار ثانيًا: hreflang، والمتون العربية غير المترجمة، ونسخ الروابط المكررة.
3. القوالب ثالثًا: Core Web Vitals والبيانات المنظمة، تُصلَح مرة واحدة لكل قالب لا صفحة بصفحة.
4. ضوابط الظهور أخيرًا: وصول زواحف الذكاء الاصطناعي، وتوثيق Bing، وIndexNow، ونظافة خريطة الموقع.

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

قبل أن تكلّف تدقيقًا جديدًا، نفّذ بنفسك اختبار الـ20 رابطًا من الملاحظة أعلاه، باستخدام فحص الرابط URL Inspection في Search Console. فإن كانت كل صفحة مهمة مفهرسة بالنسخة القانونية التي تتوقعها، فيمكن أن يكون التدقيق محدود النطاق؛ وإن لم تكن، فأنت تعرف أصلًا من أين يجب أن يبدأ.