ما هو السيو التقني الاساسيات وأفضل طرق التحسين

ما هو السيو التقني (Technical SEO)؟

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

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

في هذا الدليل سننتقل من التشخيص إلى الإصلاح: كيف يكتشف Google الصفحة؟ ما الذي يمنع فهرستها؟ وما الاختبارات التي تُجريها قبل أن تنفق الوقت على تسريع الموقع أو إضافة Schema؟

لماذا يحتاج موقعك إلى تحسين السيو التقني؟

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

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

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

الزحف: كيف تكتشف محركات البحث صفحاتك؟

كيفية عمل برامج الزحف

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

مثال تشخيصي: صفحة منتج جديدة ترد بالحالة 200 OK لكنها لا تظهر في Search Console. قبل تغيير العنوان، افحص هل يوجد رابط HTML يمكن الزحف إليه من صفحة الفئة؟ وهل يراه Google في نسخة HTML أو العرض؟ وهل يوجد noindex أو Canonical يشير إلى منتج آخر؟ ثم افحص تقرير فهرسة الصفحة؛ فالعائق قد لا يكون في الكلمات الرئيسية أصلًا.

إنشاء بنية موقع واضحة وروابط قابلة للاكتشاف

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

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

تقديم خريطة XML إلى Google Search Console

تساعد خريطة الموقع Google على اكتشاف عناوين URL المهمة، خصوصًا في المواقع الكبيرة أو حديثة الإنشاء. قد يتوفر ملفك على /sitemap.xml أو /sitemap_index.xml، لكن المسار يختلف وفق إعداد الموقع والإضافة؛ افحصه بدل افتراض وجوده.

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

أدخل رابط الخريطة في قسم Sitemaps داخل Google Search Console، ثم راجع حالة المعالجة والأخطاء والصفحات المكتشفة. قبول الخريطة لا يعني أن كل صفحة ضمنها ستُفهرس.

الفهرسة: لماذا قد تزحف Google إلى صفحة ولا تعرضها؟

بعد الزحف قد تختار Google فهرسة الصفحة أو استبعادها بناءً على الإشارات المتاحة، بما فيها قابلية الفهرسة والنسخة الأساسية وجودة المحتوى. استخدم أداة URL Inspection وتقرير الفهرسة في Search Console للصفحات المهمة. أما البحث باستخدام site:example.com فهو وسيلة استكشافية سريعة وليس جردًا كاملًا أو فحصًا حاسمًا لحالة الفهرسة؛ تؤكد Google أن نتائجه غير شاملة وقد لا تعرض صفحة مفهرسة أصلًا. توضيح Google عن عامل site:.

في التدقيق، سجّل عنوان الصفحة النهائي بعد التحويل، ورمز استجابة الخادم، وقاعدة robots، ووسم الفهرسة، والرابط الأساسي الذي أعلنته الصفحة، والرابط الذي اختارته Google عند توفره. هذا السجل يكشف الفرق بين «تم الزحف إليها ولم تُفهرس» و«عنوان بديل مع Canonical مناسب» و«صفحة محظورة»؛ وهي حالات تحتاج حلولًا مختلفة.

استخدام noindex بعناية

يمنع توجيه noindex فهرسة الصفحة عندما تتمكن Google من الوصول إليه. يمكن وضعه في رأس HTML، مثل:

<meta name="robots" content="noindex">

أو إرساله عبر ترويسة HTTP المناسبة. لا تستخدم noindex لحماية البيانات الخاصة؛ فقد تبقى الصفحة متاحة لمن يعرف رابطها، وقد تحتاج صفحات الطلبات والحسابات إلى تسجيل دخول وتحكم في الصلاحيات بدلًا من مجرد توجيه لمحركات البحث. كذلك لا تجمع حظر الصفحة في robots.txt مع noindex وتتوقع أن يقرأ Google التوجيه، لأن الحظر قد يمنع الزاحف من رؤيته أصلًا. شرح Google لتوجيه noindex.

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

استخدام Canonical لمعالجة عناوين المحتوى المتشابه

إذا أمكن الوصول إلى محتوى شديد التشابه عبر عدة روابط، يمكن توضيح الرابط المفضل بعنصر rel=”canonical” في رأس الصفحة:

<link rel="canonical" href="https://example.com/original-page/">

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

أهم تطبيقات السيو التقني داخل الموقع

HTTPS: تشفير الاتصال وضبط التحويلات

استخدم HTTPS مع شهادة TLS سليمة لحماية الاتصال بين المتصفح والخادم. يمكن الحصول على شهادة من موفر مثل Let’s Encrypt. تأكد من أن صفحات HTTP القديمة تُحوَّل إلى الوجهة HTTPS المقابلة بتحويل دائم صحيح، وأن الروابط الداخلية والخريطة وCanonical تشير إلى النسخة المطلوبة. لا تعتمد على رمز قفل بعينه في شريط العنوان؛ فواجهة المتصفح تتغير، والأهم التحقق من صلاحية الشهادة وعدم وجود موارد حساسة تُحمَّل عبر HTTP.

معالجة المحتوى المكرر ونسخ www وغير www

قد ينشأ التكرار من روابط معلمات الفرز والتصفية أو نسخ HTTP وHTTPS أو النسخ المقابلة لـwww. اختر بنية موحدة وأعلن الرابط المفضل، ثم استخدم تحويلًا دائمًا عندما تكون الصفحة القديمة قد انتقلت فعلًا إلى رابط جديد. لا توجه كل صفحة محذوفة إلى الصفحة الرئيسية؛ إذا لم يوجد بديل مناسب فقد يكون رد 404 أو 410 أدق للمستخدم والمحرك. ويجب مراجعة أثر المعلمات وصفحات التصفية حسب قيمة كل صفحة قبل فرض قواعد عامة.

سرعة التحميل وتجربة الهاتف

استخدم PageSpeed Insights مع تقارير الأداء على مستوى أنواع الصفحات، لا الصفحة الرئيسية وحدها. افحص صور الهيرو والموارد المحظورة للعرض وJavaScript الطويل والخطوط وتخزين الموارد مؤقتًا. قد يساعد ضغط الصور واستخدام صيغ مناسبة، وضبط أبعادها، وتحميل الصور غير الحرجة لاحقًا، وتحسين CDN والتخزين المؤقت. لكن لا تؤخر تحميل صورة الهيرو الكبيرة بشكل آلي إذا كانت العنصر الأساسي في LCP.

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

مؤشرات Core Web Vitals: LCP وINP وCLS

تقيس مؤشرات أداء الويب الأساسية جوانب من تجربة المستخدم الفعلية. الأهداف الجيدة هي LCP خلال 2.5 ثانية أو أقل لتحميل العنصر الأكبر، وINP بمقدار 200 مللي ثانية أو أقل للاستجابة للتفاعلات، وCLS بمقدار 0.1 أو أقل للثبات البصري. حلّ INP محل FID في مؤشرات Core Web Vitals، ولذلك لا تعتمد على FID بوصفه المقياس الحالي.

راجع بيانات المستخدمين الفعليين حيث تتوفر في Search Console وتقارير Chrome UX، واستخدم اختبارات المعمل لتشخيص السبب. قد يختلف اختبار مختبر واحد عن تجربة المستخدمين، ولا يوجد مؤشر واحد يلخص جودة الموقع أو يضمن ترتيبه. مرجع Google للمقاييس.

مسارات التنقل Breadcrumbs

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

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

ترقيم الصفحات مقابل التمرير اللانهائي

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

راجع ملف robots.txt دون الخلط بين الزحف والفهرسة

يكون ملف robots.txt عادة في جذر النطاق، مثل https://example.com/robots.txt. يحدد مسارات يُسمح للروبوتات بالزحف إليها أو يُطلب منها تجنبها؛ لكنه ليس أداة لحماية الملفات الخاصة أو ضمان إزالة عنوان من نتائج البحث. تحقق من عدم حظر CSS أو JavaScript الضروريين للعرض، ومن عدم حظر صفحات المنتجات والمقالات المهمة. إذا كان الهدف عدم الفهرسة فراجع noindex وإتاحة الزحف إليه، أو حماية الوصول عندما يتعلق الأمر ببيانات خاصة.

البيانات المنظمة Schema: فهم المحتوى وليس وعدًا بنتيجة غنية

استخدم نوع Schema الذي يطابق البيانات الظاهرة فعلًا في الصفحة. في المتجر يمكن لبيانات Product توضيح معلومات المنتج وتوافره عندما تستوفي المتطلبات؛ وفي الصفحات الأخرى قد تكون BreadcrumbList مناسبة. اختبر التنفيذ عبر Rich Results Test ووثائق Google الخاصة بنوع البيانات. البيانات المنظمة الصحيحة قد تمنح الصفحة أهلية لبعض المظاهر، لكنها لا تضمن عرض Rich Result أو ارتفاع CTR. سياسة البيانات المنظمة.

اكتشاف الصفحات المعطلة والتحويلات الخاطئة

افحص الروابط الداخلية التي تقود إلى 404، وسلاسل التحويلات الطويلة، وأخطاء 5xx، والصفحات التي تعيد 200 رغم عرض رسالة «الصفحة غير موجودة» (Soft 404). استعن بزاحف موقع أو Semrush Site Audit عند توفره، ثم صحح الرابط الداخلي إلى الوجهة النهائية، أو استعد المحتوى إذا حُذف خطأً، أو ضع تحويلًا إلى بديل مكافئ. لا تنقل الزائر إلى صفحة غير مرتبطة لمجرد إخفاء خطأ.

hreflang للمواقع متعددة اللغات والمناطق

إذا كانت لديك نسخ لصفحة بلغات أو مناطق مختلفة، استخدم hreflang للإشارة إلى علاقة النسخ المتكافئة. يمكن تطبيقها في HTML أو ترويسات HTTP أو خريطة XML، مع روابط متبادلة وعناوين صحيحة لكل نسخة. لا تستخدمها لمعالجة محتوى مكرر في لغة واحدة، ولا تخلط بينها وبين Canonical؛ يجب التحقق من اتساقهما. وهي تساعد Google على اختيار النسخة الأنسب، دون أن تضمن ظهورها لكل مستخدم. وثائق Google عن النسخ المحلية.

JavaScript SEO: هل يرى الزاحف المحتوى الفعلي؟

إذا كانت قائمة المنتجات أو تفاصيل المقال لا تظهر إلا بعد تنفيذ JavaScript، افحص HTML الأولي ثم النسخة المعروضة باستخدام أداة URL Inspection. تستطيع Google عرض كثير من صفحات JavaScript، لكن انتظار العرض أو تعذر جلب موارد مهمة قد يؤخر اكتشاف المحتوى. تأكد من وجود روابط بعناصر a href إلى الوجهات المهمة، وراجع الصور المحملة بتأخير والبيانات المنظمة. وقد يساعد العرض المسبق أو من جهة الخادم في جعل المحتوى متاحًا باكرًا للزائر والزاحف، لكنه ليس شرطًا إلزاميًا لكل موقع. دليل JavaScript SEO.

كيف ترتب أولويات السيو التقني؟

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

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

قائمة فحص عملية للتشخيص

1. حدد صفحات وعينات ممثلة: الرئيسية، والفئات، وصفحات المنتجات، والمقالات، وصفحات الخدمات.
2. تحقق من رمز HTTP النهائي، والتحويلات، والرابط الأساسي، ووسم robots، وإتاحة HTML أو العرض.
3. قارن تقرير URL Inspection وحالة الفهرسة مع صفحات الموقع المقصودة، ولا تعتمد على نتيجة site: وحدها.
4. افحص بنية الروابط الداخلية والصفحات اليتيمة، ثم راجع خريطة XML وتناسقها مع Canonical.
5. افحص عينات الهاتف وCore Web Vitals، وحدد العنصر أو مهمة JavaScript التي تفسر التأخر قبل التعديل.
6. تحقق من البيانات المنظمة ومطابقتها للمحتوى المرئي، ومن عناوين اللغات المختلفة عند وجودها.
7. سجّل الإجراء والصفحات المتأثرة وخط الأساس ثم أعد الفحص بعد الإصلاح، مع تجنب تغيير عدة متغيرات كبيرة دون سجل.

أسئلة شائعة في السيو التقني

هل إرسال Sitemap يضمن فهرسة كل صفحات الموقع؟

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

هل يكفي ضبط robots.txt لمنع ظهور صفحة خاصة؟

لا. الملف يتحكم في الزحف ولا يفرض حماية الوصول. استخدم صلاحيات وتسجيل دخول للبيانات الخاصة، وتعليمات الفهرسة المناسبة للصفحات العامة التي لا تريد ظهورها.

هل ارتفاع CLS أو INP يعني عقوبة مباشرة؟

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

الخلاصة

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