التدقيق التقني لـSEO: كيف تفحص الزحف والفهرسة والسرعة؟

التدقيق التقني لـSEO هو عملية تشخيص لمسار الصفحة من الخادم إلى الزحف والفهرسة ثم الظهور، وليس قائمة نصائح عامة عن الكلمات المفتاحية. الهدف أن تعرف أين يتعطل المحتوى: هل لا يستطيع محرك البحث الوصول إليه؟ هل يصل إليه لكنه لا يختار فهرسته؟ هل توجد نسخ متنافسة؟ أم أن الصفحة بطيئة أو مربكة للمستخدم؟ لكل سؤال دليل وفحص مختلف.

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

ابدأ بنطاق ولقطة بيانات

ثبّت النطاق: البروتوكول، النطاق الأساسي، المجلدات، أنواع الصفحات، والبيئات التي يجب استبعادها. اجمع لقطة من Search Console، وملف robots.txt، وsitemap، وحالة الاستجابات، وأهم القوالب. سجّل تاريخ الفحص حتى لا تخلط بين عطل قديم وتغيير حديث. لا تغيّر ملفًا أو توجيهًا أثناء القياس؛ وإلا فقدت خط الأساس.

قسّم الصفحات إلى رئيسية، خدمات، مقالات، تصنيفات، بحث، ونسخ معاملات. كل نوع قد يملك قواعد مختلفة. احتفظ بعينة عناوين وروابط canonical وrobots وstatus code؛ التدقيق الجيد قابل لإعادة التشغيل ويشرح ما تغيّر، لا يكتفي بدرجة واحدة.

افحص قابلية الزحف أولًا

الزحف هو قدرة محرك البحث على اكتشاف الرابط وطلبه. راجع الروابط الداخلية القابلة للنقر، وحالات 200 و3xx و4xx و5xx، وسلاسل التحويل، والروابط التي لا يمكن الوصول إليها إلا عبر JavaScript. افحص robots.txt للتأكد من أنه لا يحجب مسارات تريد ظهورها، ولا يفتح بيئة إدارية أو مؤقتة. توضح Google قواعد التعامل مع ملف robots.txt في المرجع الرسمي.

قارِن الروابط الموجودة في sitemap بما يربط إليه الموقع فعليًا. لا تضع صفحات noindex أو canonical لصفحة أخرى في sitemap على أنها أهداف أساسية. أصلح الروابط اليتيمة بإضافة سياق مناسب من صفحة ذات صلة، ولا تضف عشرات الروابط لمجرد زيادة العدد. عند وجود متجر أو فلاتر، حدّد المعلمات التي تنتج نسخًا لا تضيف قيمة.

افصل قابلية الوصول عن قرار الفهرسة

استجابة 200 لا تعني أن الصفحة مفهرسة. افحص تقرير Page indexing في Search Console واختبر عناوين نموذجية بأداة URL Inspection. ابحث عن noindex غير المقصود، أو صفحة فارغة، أو تحويل إلى نسخة أخرى، أو محتوى مكرر. اعتمد على HTML النهائي الذي يراه المتصفح ومحرك البحث، لا على ملف القالب وحده.

إذا كانت الصفحة مهمة، فاجعلها قابلة للاكتشاف من روابط داخلية واضحة وضمن sitemap نظيفة. لا تطلب الفهرسة لعشرات الصفحات المتشابهة دفعة واحدة قبل إصلاح القالب. وثّق الفرق بين “تم اكتشافها” و“تم الزحف إليها” و“تمت فهرستها”، لأن كل حالة تحتاج خطوة مختلفة.

canonical وإشارات النسخ

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

اختبر نسخ www وnon-www وHTTP وHTTPS، والشرطة المائلة، ومعلمات التتبع. يجب أن تقود النسخ غير الأساسية إلى تحويل ثابت مناسب، وأن تتطابق الروابط الداخلية مع العنوان الأساسي. عند تغيير slug، خطط لتحويل 301 واحد وتحقق من عدم وجود سلسلة طويلة.

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

راجع sitemap وstructured data

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

افحص breadcrumb وArticle أو Service حيث تنطبق، وتأكد من عدم وجود مالكين متنافسين للـschema. عندما يكون الموقع مبنيًا على WordPress، حدّد مصدر SEO واحدًا حتى لا تكرر title وcanonical وschema من إضافات وقالب في آن واحد.

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

السرعة وCore Web Vitals

ابدأ ببيانات المستخدم الميدانية إن وجدت، ثم استخدم اختبارًا مخبريًا لتحديد السبب. راقب LCP لعنصر المحتوى الرئيسي، وINP للتفاعل، وCLS للاستقرار البصري، ولا تختزل الأداء في رقم Lighthouse واحد. راجع شرح Google الرسمي لـCore Web Vitals وحدود القياس قبل اقتراح إصلاح.

ابحث عن صورة بطل كبيرة، CSS أو JavaScript حاجب، خطوط كثيرة، طلبات طرف ثالث، وغياب أبعاد الصور. أصلح ما يؤثر على القالب كله أولًا: تحميل الصور المتجاوب، تقليل الموارد، تثبيت المساحات، ثم انتقل إلى صفحة بعينها. لا تؤخر محتوى مهمًا في اسم “تحسين الأداء”، ولا تحذف أدوات قياس بلا بديل.

سجّل الجهاز والاتصال وحجم الصفحة عند كل اختبار، فالفروقات قد تفسر نتيجة متذبذبة. افصل زمن الخادم عن زمن الرسم في المتصفح، وافحص السجل الشبكي لمعرفة المورد الذي يؤخر العنصر الرئيسي. بعد التعديل اختبر الصفحة الرئيسية وصفحة خدمة ومقالًا؛ إصلاح قالب واحد قد يحسن عشرات الصفحات، بينما تحسين صورة منفردة لا يعالج أصل المشكلة.

ترتيب الإصلاحات حسب الأثر والثقة

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

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

1. أوقف الحجب أو التحويلات التي تمنع الصفحات الأساسية.
2. وحّد النطاق وcanonical وsitemap والروابط الداخلية.
3. أصلح القوالب التي تنتج عناوين أو محتوى أو schema متكررًا.
4. حسّن Core Web Vitals للمسارات ذات الزيارات أو القيمة التجارية.
5. أعد الزحف والاختبار، ثم راقب Search Console قبل الحكم على الأثر.

ما الذي لا يثبته التدقيق؟

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

تقرير مهني قابل للتنفيذ

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