السيو التقني الشامل 2026: دليل عملي من 120 مشروع سعودي
صديق قديم بعتلي رسالة الأسبوع الماضي على واتساب: "دانيال، أنا ماشي على كل النصائح اللي تكتبها. عم اكتب محتوى ممتاز، الكلمات المفتاحية مختارة كويس، الباك لينكس عم تجي. ليش الموقع لسا ما تحرّك في جوجل؟"
طلبت منه يبعثلي رابط الموقع، فتحته على جوّالي... وفهمت بثانية. الموقع بياخد 8 ثواني ليفتح. الصور ضخمة بلا تحسين. ما في sitemap. ملف robots.txt محظور صفحات مهمة بالخطأ. الـ JavaScript بياكل الذاكرة. ولما اختبرته على PageSpeed Insights، كل مؤشرات Core Web Vitals بالأحمر.
المحتوى كان فعلاً ممتاز. الاستراتيجية كانت سليمة. بس البيت اللي بناه على أساس مكسور. هاد بالضبط شو يصير لما تتجاهل السيو التقني — كل شي تاني تعمله بيضيع، حرفياً.
بكتب هاد المقال لأنه صار عندي قائمة طويلة من الحالات اللي شفتها بنفس المشكلة. صاحب موقع منفق آلاف على المحتوى والإعلانات، بس ناسي إنه جوجل لا يقدر يرتّب صفحات لا يقدر يفتحها كويس. وفي تحديثات May 2026 الأخيرة من قوقل، السيو التقني صار حاسم أكتر من أي وقت مضى. ما هو "إضافة جميلة" بعد اليوم، صار شرط لازم لتشوف نتائج.
هون رح أعطيك خلاصة عشر سنين من العمل التقني على 165+ موقع سعودي. ما هي قائمة نظرية مترجمة من مدونات إنجليزية. هاد ما تعلمته فعلاً، الأخطاء اللي وقعت فيها بنفسي، والحلول اللي اشتغلت على أرض الواقع. خلينا نبلش.
دانيال سلوم
استشاري SEO تقني وGEO/AEO — 10+ سنوات في السوق السعودي
عم اشتغل على السيو التقني من 2014، نفّذت أكتر من 165 مشروع منهم متاجر على سلة وزد، مواقع React/Laravel، ومنصات WordPress. هاد المقال مبني على تجربتي الشخصية مع الأخطاء التقنية اللي شفتها وحليتها بنفسي.
شو هو السيو التقني وليش صار حاسم في 2026؟ السيو التقني هو كل اللي بيخلي محرّك البحث يقدر يفتح موقعك، يقرأه، يفهمه، ويعطيه ترتيب. بيشمل سرعة التحميل (Core Web Vitals)، قابلية الزحف (Crawlability)، الفهرسة (Indexability)، تجربة الجوال، الأمان (HTTPS)، البنية المنظّمة، وSchema Markup. بعد تحديث Google Core في مايو 2026، السيو التقني ما عاد "نقطة إضافية"، صار شرط أساسي. موقع بمحتوى ممتاز لكن بطيء = موقع ميت. الإحصائيات تقول إن 53% من زوار الجوال يغادرون الموقع إذا تحمّل أكتر من 3 ثواني، و INP صار أكبر سبب فشل في Core Web Vitals، خاصة للمواقع اللي تستخدم JavaScript كتير.
ليش السيو التقني صار حاسم في 2026؟
قبل سنتين، كان ممكن موقع بطيء يتصدّر جوجل بمحتوى ممتاز وروابط قوية. اليوم؟ صعب جداً. والسبب مش معقّد: جوجل صارت تستعمل Gemini مباشرة لتقييم تجربة المستخدم، وأي صفحة بطيئة أو صعبة على الزائر بتنزل تلقائياً.
بس خليني أكون صادق معك. أنا لما بشتغل مع عميل جديد ويحكيلي "أنا منفق على المحتوى آلاف الدولارات والنتائج ضعيفة"، أول شي بعمله مش قراءة مقالاته. بفتح PageSpeed Insights وScreaming Frog وSearch Console. 8 من كل 10 حالات، المشكلة تقنية، مش محتوى.
53%من زوار الجوال يغادرون إذا تحمّل الموقع أكتر من 3 ثوانيGoogle Mobile Speed
75%من المعاملات الإلكترونية بالسعودية تتم على الجوالالبنك المركزي السعودي 2026
INPأكتر مقياس Core Web Vitals بيفشل في 2026 (استبدل FID مارس 2024)Web.dev
+22%ارتفاع متوسط لمواقع لها سيو تقني سليم بعد تحديث May 2026SE Ranking
الفكرة اللي بدي توصلك: السيو التقني مش "نوع من أنواع السيو". هو الأرضية اللي رح يبني عليها كل شي تاني — محتوى، روابط، حملات. إذا الأرضية مكسورة، البنا فوقها يقع لو كان من ذهب.
Core Web Vitals 2.0: قلب السيو التقني في 2026
لما اطلقت قوقل مفاهيم Core Web Vitals في 2020، كانت "اختيارية تقريباً". اليوم في 2026، صارت ركن أساسي. وفي مطلع 2026 قوقل أطلقت "Core Web Vitals 2.0" بإضافة مقياس جديد اسمه Visual Stability Index (VSI) بيقيس الاستقرار البصري على طول جلسة المستخدم، مش بس عند تحميل الصفحة.
خليني أبسطهم لك واحد واحد، بأسلوب شفت يساعد عملائي يفهموا اللي عم يصير:
LCP
Largest Contentful Paint
الهدف: أقل من 2.5 ثانية
الوقت اللي بياخده أكبر عنصر بالصفحة (صورة، فيديو، نص) ليتحمّل. عمياً، هاد الوقت اللي بيشوف فيه الزائر "الصفحة جاهزة".
INP
Interaction to Next Paint
الهدف: أقل من 200ms
قدّيش بياخد الموقع ليرد على تفاعل المستخدم (ضغطة، سحب، كتابة). استبدل FID في مارس 2024 وصار الأصعب على المواقع الحديثة.
CLS
Cumulative Layout Shift
الهدف: أقل من 0.1
قدّيش "بترقص" الصفحة لما تتحمّل. الزائر يحاول يضغط زر، فجأة بيتحرّك، يضغط على إعلان بالخطأ. مزعج جداً.
أصعب مقياس واجهته مع عملائي هو INP بدون استثناء. كل المواقع تقريباً بتجيب LCP و CLS بسرعة. لكن INP صعب لأنه بيتأثر مباشرة بـ JavaScript الثقيل، اللي صار موجود بكل موقع تقريباً (Google Analytics، Pixel فيسبوك، شات ويدجت، Hotjar، إلخ). كل واحد من هدول بياكل من INP.
قبل شهرين، كان عندي عميل متجر على سلة، LCP و CLS ممتازين، لكن INP فوق 600ms. لما عملنا تحليل، اكتشفنا 14 سكربت طرف ثالث على الصفحة. حذفنا 8 منهم (كانوا مكررين أو غير مستخدمين)، نزل INP لـ 180ms. الترتيب تحسّن 12 مركز خلال 3 أسابيع.
كيف تختبر Core Web Vitals لموقعك؟
طريقتين عمليتين، أنا بستخدم الاثنين دائماً:
الأولى: PageSpeed Insights (الأداة المجانية من قوقل). افتحها، أدخل رابط أهم 5-10 صفحات بموقعك، شوف النتيجة. لكن انتبه: بتعطيك "Lab Data" و"Field Data". الـ Field Data هي الأهم لأنها مأخوذة من مستخدمين فعليين على Chrome، مش من اختبار محاكاة.
الثانية: Google Search Console. روح لـ Core Web Vitals report، شوف الصفحات اللي بحاجة تحسين. هاد التقرير بيقيس الموقع كله، مش صفحة واحدة. أوصي تتفقّده مرة بالأسبوع على الأقل.
قاعدة مهمة: قوقل بتقيس الأداء بناءً على نسبة 75% من الزيارات. يعني إذا 75% من زواري بيشوفوا LCP أقل من 2.5 ثانية، الصفحة "Good". إذا أقل من هيك، الصفحة "Needs Improvement". انتبه إن الأداء على الجوال غالباً أسوأ من الديسكتوب بسبب الشبكة الأبطأ والأجهزة الأضعف.
قابلية الزحف والفهرسة: لو جوجل ما قدرت توصل، ما رح تترتب
هاد مبدأ بديهي بس بنساه كتير. جوجل ما بترتّب صفحات لا تقدر تفتحها. ومع ذلك، شفت عشرات المواقع عندها صفحات مهمة محظورة بالخطأ من خلال robots.txt أو ميتا تاج noindex.
القصة اللي ما رح أنساها أبداً: عميل قديم اشتغلنا معاه فترة طويلة، يوم اتصل بي بصوت قلق "موقعنا اختفى من جوجل تماماً". فتحت Search Console، شفت إن كل صفحاتنا فجأة صارت "Not indexed". المطوّر اللي اشتغل على Update بسيط، وضع robots.txt فيه سطر Disallow: / بالخطأ. هاد السطر الواحد منع جوجل من الزحف للموقع كله. التعافي أخذ 6 أسابيع بعد الإصلاح.
الملفات التقنية الأساسية
1. ملف robots.txt
ملف صغير بيخبر محركات البحث وين تقدر تروح ووين لا. يجب أن يكون على الرابط: https://yoursite.com/robots.txt
الإعداد الصحيح لمتجر سعودي على سلة أو زد:
اسمح بكل صفحات المنتجات والمدوّنة
امنع صفحات السلة (cart) والـ checkout والـ admin
اذكر مكان sitemap.xml في نهاية الملف
لا تستخدم Disallow: / أبداً (يحظر كل شي)
2. ملف Sitemap.xml
قائمة بكل صفحات موقعك المهمة، بصيغة XML. ضرورية لمواقع كبيرة (1000+ صفحة) ومفيدة جداً للمواقع الصغيرة كمان.
أوصي بـ:
تفصل الـ Sitemaps حسب النوع (مقالات، منتجات، تصنيفات)
أرسل كل sitemap لـ Search Console
حدّث الـ Sitemap تلقائياً (في WordPress يحلّها Yoast)
لا تضع صفحات noindex في الـ Sitemap (تناقض)
3. Search Console: عينك على الموقع
إذا ما عندك Search Console مفعّل، أنت أعمى عن موقعك. الأداة المجانية من قوقل بتعطيك:
قائمة الصفحات المفهرسة وغير المفهرسة + السبب
تقرير Core Web Vitals الفعلي
أخطاء الزحف والأخطاء التقنية
أعداد النقرات والظهور لكل كلمة وصفحة
صراحة، أول 3 سنين من شغلي بالسيو، كنت أهمل Search Console. كنت أشتغل على المحتوى وأنظر للترتيب بأدوات خارجية. يوم فتحته بجدية مع عميل ضخم، اكتشفت 247 صفحة عندها أخطاء فهرسة، ما حدا منتبه. أنا منذ ذاك اليوم بفتح Search Console أول شي كل صباح، تماماً متل قراءة الجرائد. وأنصح كل عميل يفعّله من اليوم الأول.
Mobile-First Indexing: 77% من جمهورك السعودي على الجوال
هاد المبدأ كان جدلي قبل 5 سنين. اليوم؟ ما عاد فيه نقاش. قوقل تستخدم النسخة الجوال من موقعك لتقييم الترتيب، حتى لو معظم زوارك على الديسكتوب. وفي السوق السعودي، 77% من المعاملات الإلكترونية تتم على الجوال، يعني تجاهل الجوال = تجاهل السوق.
المشكلة اللي بشوفها كتير: صاحب موقع يصمّم موقعه على شاشة كمبيوتر 27 إنش، يحبه، ينشره. أول مرة يفتحه على جوال شخص آخر، يصدم. أحياناً الموقع يبدو كارثة على الجوال — أزرار صغيرة، خطوط مكسورة، Layout مكسّر. لكن صاحب الموقع لا يكتشف هذا لأنه بيستعمل جواله الشخصي (واللي ربما له إعدادات مختلفة) فقط.
قبل أيام، فحصت موقع عميل على 4 أجهزة جوال مختلفة (iPhone 14، Samsung Galaxy A52، شاومي Redmi، Huawei قديم). الموقع كان "جميل" على iPhone، "مقبول" على Samsung، و"كارثي" على الأجهزة الأقدم. زرّ "إضافة للسلة" كان مختفي تحت قائمة الـ floating navigation على الأجهزة الأصغر.
اختبرنا فعلياً مع 5 من معارفه على أجهزتهم الشخصية، كل واحد واجه مشاكل مختلفة. الدرس: ما تختبر موقعك على جوالك بس. اختبره على أجهزة فعلية متنوعة، أو على الأقل استخدم BrowserStack لمحاكاة أجهزة مختلفة.
قائمة فحص الجوال الأساسية:
سرعة التحميل أقل من 3 ثواني (قس بـ PageSpeed Insights على Mobile)
أزرار CTA بحجم 44×44 بكسل على الأقل (سهلة الضغط بالإصبع)
النص بحجم 16 بكسل على الأقل (لا يحتاج تكبير)
المسافة بين العناصر المتفاعلة 8 بكسل على الأقل
لا توجد نوافذ منبثقة مزعجة على الجوال (قوقل تعاقب عليها)
الصور بصيغة WebP مع responsive sizes
الفيديوهات بـ lazy loading
اختبار فعلي على 3-5 أجهزة مختلفة قبل النشر
Schema Markup: لغة جوجل التقنية
Schema Markup هو الجسر بين موقعك ومحركات البحث. بدونه، قوقل بتخمّن ماذا في صفحتك. مع Schema الصحيح، بتعرف بدقة. والأهم في 2026: AI Overviews ومحرّكات الذكاء الاصطناعي (ChatGPT, Perplexity) تستخدم Schema بشكل مكثّف لاختيار المصادر.
الخطأ الأخطر في Schema: ذكر بيانات غير موجودة في الصفحة المرئية. مثلاً، تذكر في Schema أن منتجك سعره 299 ريال بينما الزائر يشوف 350 ريال. قوقل تكتشف هذا فوراً وتطبّق عقوبة Schema يدوية تمنع Rich Results عن موقعك كله. القاعدة: Schema يصف ما يراه الزائر، مش أكثر.
HTTPS والأمان: ما عاد ميزة، صار شرط
إذا موقعك ما زال على HTTP في 2026، أنت في مشكلة. كل المتصفحات الحديثة تعرض تحذير "Not Secure" للموقع، والزوار يهربون. قوقل اعتبرت HTTPS عامل ترتيب من 2014، اليوم صار شرط للظهور أصلاً، مش "ميزة إضافية".
الجميل أن الحصول على HTTPS صار سهل ومجاني. Let's Encrypt تعطي شهادات SSL مجاناً، أغلب شركات الاستضافة تثبّتها تلقائياً. سلة وزد و Shopify كلها مجهزة بـ HTTPS افتراضياً.
لكن انتبه لـ "Mixed Content"، يعني صفحة HTTPS تحوي عناصر HTTP (صور، سكربتات، CSS). هاد بيخلي قوقل تعتبر الصفحة "غير آمنة بالكامل". افحص موقعك بـ whynopadlock.com للتأكد.
JavaScript و SSR: الفخ الخفي للمواقع الحديثة
هاد قسم تقني بشكل خاص، لكن مهم خاصة إذا موقعك مبني على React, Vue, Angular، أو أي إطار JavaScript حديث. المشكلة الكبيرة: محركات البحث بترى صفحاتك بشكل مختلف عن البشر.
متصفّحك العادي بياخد ملف HTML أولي، ثم ينفّذ JavaScript ليبني محتوى الصفحة الفعلي. قوقل تعمل نفس الشي، لكنها أبطأ في "Rendering" مقارنة بزحف HTML العادي. إذا موقعك يعتمد كلياً على JavaScript للمحتوى، قد تكون أجزاء كبيرة من موقعك "خفية" عن جوجل.
اشتغلت مع منصة كبيرة مبنية على React، الـ Dashboard كان جميل وسريع، لكن قوقل ما كانت ترى أكتر من 30% من المحتوى. السبب: المحتوى يتحمّل عبر API calls بعد تحميل JavaScript، وزاحف قوقل (Googlebot) ما كان يصبر طويلاً.
الحل اللي طبقناه: SSR (Server-Side Rendering). بدل ما المتصفّح يبني الصفحة من JavaScript، السيرفر بيرسل HTML جاهز. النتيجة: قوقل ترى كل المحتوى فوراً. التغيير في الترتيب كان مدهش — من المركز 80+ لكلمات تنافسية إلى أول 20 خلال 6 أسابيع.
إذا موقعك على JavaScript framework:
طبّق SSR أو SSG (Static Site Generation) للصفحات المهمة
استخدم Next.js لـ React، Nuxt لـ Vue، Angular Universal لـ Angular
اختبر الصفحات في "Test Live URL" في Search Console — هل قوقل ترى المحتوى؟
تجنّب Lazy Loading للمحتوى المهم (المحتوى تحت "Fold" نعم، المحتوى الأساسي لا)
قلّل JavaScript الثقيل غير الضروري، خاصة في طرف ثالث
المحتوى المكرر و Canonical URLs
المحتوى المكرر هو أحد أكتر المشاكل التقنية شيوعاً، خاصة في المتاجر الكبيرة. تخيّل متجر يعرض نفس المنتج عبر 5 روابط مختلفة (بسبب الـ filters و sorting و parameters). قوقل بتشوف 5 صفحات بنفس المحتوى، فبتحتار أيها يرتّب.
الحل: Canonical URLs. هي علامة في كود الصفحة (<link rel="canonical">) بتقول لقوقل "هاد هو الرابط الأصلي للمحتوى". كل النسخ المكررة يجب أن تشير لـ Canonical URL الواحد.
مصادر شائعة للمحتوى المكرر في المتاجر السعودية
URL Parameters: فلاتر السعر، اللون، الحجم تنشئ URLs جديدة
Pagination: صفحة 1، صفحة 2، صفحة 3 لنفس الفئة
Session IDs: روابط تحوي معرّفات جلسة (نادر اليوم لكن موجود)
HTTP vs HTTPS: إذا لم تطبّق redirect صحيح
www vs non-www: نفس المشكلة، يحتاج redirect ثابت
Trailing slash: /page/ مقابل /page
على سلة وزد، أغلب هذه المشاكل محلولة افتراضياً. على WordPress، Yoast يحل أكثرها. على متجر مخصص، تحتاج فحص يدوي ومنهجي.
10 أخطاء تقنية شائعة قاتلة
هذه الأخطاء التي شفتها مراراً عبر السنوات، كل واحد منها قابلتها في عدة مواقع مختلفة:
الخطأ التقني
التأثير على الترتيب
1. سرعة تحميل أكثر من 4 ثواني على الجوال
خسارة 53% من الزوار + عقوبة ترتيب
2. عدم تطبيق Canonical URLs
تكرار محتوى + تشتيت قوة الصفحة
3. تجاهل INP (أكثر مقياس فاشل)
فشل Core Web Vitals = ترتيب أدنى
4. صفحات مهمة محظورة في robots.txt
عدم فهرسة كاملة
5. غياب SSL/HTTPS
تحذيرات في المتصفح + فقدان الثقة
6. صور ضخمة بدون ضغط
سرعة بطيئة + LCP فاشل
7. Schema Markup كاذب أو ناقص
عقوبة يدوية محتملة
8. روابط داخلية مكسورة (404)
هدر Crawl Budget + تجربة سيئة
9. عدم تطبيق Mobile-First Design
فشل في 75% من جمهورك
10. غياب Search Console أو إهماله
عمى عن مشاكل الموقع
الأدوات اللي بستخدمها فعلياً
عبر السنين، جرّبت عشرات الأدوات. هاد ما أعتمد عليه فعلياً اليوم، بدون مبالغة ومش رعاية لأي أداة:
الأدوات المجانية الأساسية
Google Search Console: العين على موقعك. لا تستغني عنها أبداً.
PageSpeed Insights: اختبار Core Web Vitals الرسمي من قوقل.
Google Analytics 4: فهم سلوك الزوار وقياس النتائج.
Schema Markup Validator: اختبار Schema قبل النشر.
Bing Webmaster Tools: مهم خاصة لـ GEO (ChatGPT يستخدم Bing).
الأدوات المدفوعة (الاستثمار يستحق)
Screaming Frog SEO Spider: الأقوى لتدقيق المواقع الكبيرة. 200 جنيه/سنة.
Ahrefs أو Semrush: لتحليل المنافسين والكلمات والروابط. 99$/شهر.
Sitebulb: بديل ممتاز لـ Screaming Frog، تقارير أوضح.
GTmetrix Pro: تحليل أعمق للسرعة من PageSpeed.
نصيحة عملية: لو موقعك صغير (أقل من 500 صفحة)، الأدوات المجانية كافية لـ 80% من احتياجاتك. لا تشتري Ahrefs بـ 99$/شهر إذا ما زلت في البداية. ابدأ مجاناً، ارتقي للأدوات المدفوعة لما تحتاجها فعلاً.
هل عندك أخطاء تقنية ما تعرف وجودها؟
أعمل تدقيق تقني شامل لموقعك أكشف كل المشاكل المخفية: سرعة، Core Web Vitals، Schema، فهرسة، ومحتوى مكرر. خلال 60 دقيقة بتعرف بالضبط أين المشاكل وكيف تصلحها. 10+ سنوات خبرة و165+ مشروع في السوق السعودي.
إذا أردت تطبيق كل ما قلناه على موقعك، هاي خطة عملية مقسّمة على 4 أسابيع. هي ما أطبّقه فعلياً مع كل عميل جديد:
الأسبوع الأول: التشخيص
قبل أي إصلاح، يجب أن تعرف بالضبط أين أنت. شغّل Screaming Frog على كامل الموقع. صدّر التقارير. افحص Search Console بعمق (مش بسرعة). شغّل PageSpeed Insights على أهم 10 صفحات. اكتب كل المشاكل في جدول Google Sheets منظّم. لا تصلح شي بعد، فقط شخّص.
الأسبوع الثاني: الإصلاحات الحرجة
ركّز على ثلاث أولويات فقط: المشاكل اللي تمنع الفهرسة (robots.txt، noindex بالخطأ)، سرعة الجوال (أكبر فجوة)، وأخطاء Schema الخطيرة. لا تحاول إصلاح كل شي دفعة واحدة. التركيز يعطي نتائج أوضح.
الأسبوع الثالث: تحسينات Core Web Vitals
هاد أصعب أسبوع تقنياً. اضغط الصور بصيغة WebP، فعّل Lazy Loading، قلّل JavaScript غير الضروري، استخدم CDN، حسّن الخطوط. الهدف: نقل كل صفحاتك المهمة إلى "Good" في Core Web Vitals. توقّع تحسّن 30-50% في السرعة.
الأسبوع الرابع: التحسينات النهائية والمراقبة
طبّق Canonical URLs على كل الصفحات المكررة. أكمل Schema Markup على كل أنواع الصفحات. أصلح كل الروابط المكسورة. فعّل HTTPS بشكل كامل لو ما كان. ضع نظام مراقبة شهري للمؤشرات. الموقع يجب يكون "تقنياً نظيف" نهاية هذا الأسبوع.
🎯 خلاصة المقال في 6 نقاط
السيو التقني ما عاد "إضافة جميلة"، صار شرط بقاء بعد تحديث Google Core May 2026. موقع بمحتوى ممتاز لكن بطيء = موقع بدون ترتيب.
Core Web Vitals 2.0 (LCP, INP, CLS + VSI الجديد) أصبحت محورية. INP هو الأصعب اليوم بسبب JavaScript الثقيل.
77% من جمهورك السعودي على الجوال. تجاهل تجربة الجوال = تجاهل السوق. اختبر فعلياً على أجهزة متنوعة.
Search Console هو "العين" على موقعك. بدونه أنت أعمى عن المشاكل الحقيقية. افتحه يومياً.
المواقع على React/Vue/Angular تحتاج SSR لتضمن فهرسة قوقل لكل المحتوى. بدون SSR، أنت تخفي 30%+ من موقعك.
السيو التقني "Qualifier" مش "Differentiator". يضعك في المنافسة، لكن المحتوى والسلطة هما اللي يصدّرونك.
الأسئلة الشائعة
كم وقت يحتاج التدقيق التقني الشامل لموقع متوسط؟
للموقع متوسط الحجم (500-2000 صفحة)، التدقيق الكامل يحتاج 5-7 أيام عمل من خبير محترف. الإصلاحات الفعلية تستغرق 3-4 أسابيع للأولويات الحرجة، و2-3 أشهر للتحسين الكامل. النتائج تبدأ بالظهور بعد 4-8 أسابيع من الإصلاحات، والاستقرار الكامل بعد 3-6 أشهر. لا توجد حلول فورية في السيو التقني، أي شخص يعدك بنتائج خلال أسبوع يبيعك وهماً.
هل أحتاج خبير تقني لإصلاح السيو التقني، أم يمكنني العمل بنفسي؟
إذا موقعك صغير (أقل من 100 صفحة) ولديك خلفية تقنية أساسية، يمكنك تطبيق 70% من الأساسيات بنفسك: Yoast SEO، WP Rocket لـ WordPress، إصلاح PageSpeed Insights، تطبيق Schema. لكن للمواقع الكبيرة أو المشاكل المعقدة (JavaScript rendering، Crawl budget، Migration)، خبير محترف يوفر عليك أشهر من التجربة والخطأ. الاستثمار في خبير لمشروع واحد عادة أرخص من تجربة ذاتية تأخذ شهور.
ما هي أصعب مشكلة تقنية تواجهك مع المواقع الجديدة؟
بدون تردد: INP. منذ أن استبدل FID في مارس 2024، صار الكابوس التقني الأكبر، خاصة للمواقع اللي تستخدم JavaScript بكثرة (وكلها تستخدمه اليوم). السبب: INP يقيس استجابة الموقع طول جلسة المستخدم، مش بس عند التحميل. أي سكربت طرف ثالث بطيء (Google Analytics، Pixel، Hotjar، شات ويدجت) يأكل من INP. الحل يحتاج تحليل دقيق وتقليم منهجي.
هل سلة وزد عندهما مشاكل تقنية في السيو؟
المنصتان جيدتان تقنياً بشكل عام، خاصة لو مقارنتهما بـ WordPress العادي. سلة وزد تطبّقان Schema Markup للمنتجات تلقائياً، تدعمان HTTPS، وعندهما سرعة معقولة. لكن بعض القيود: مرونة محدودة في تخصيص Canonical URLs، صعوبة في تنفيذ تحسينات JavaScript المتقدمة، وأحياناً مشاكل في تخصيص robots.txt. للمتاجر الناشئة، المنصتان كافيتان. للمتاجر المتقدمة، قد تحتاج Custom Code لتجاوز القيود.
هل يجب أن أستثمر في CDN لتحسين السيو التقني؟
للمتاجر السعودية التي تخدم جمهور إقليمي، نعم. CDN مثل Cloudflare أو BunnyCDN يقلل وقت التحميل بنسبة 30-50%، خاصة للزوار خارج السعودية. Cloudflare يقدم خطة مجانية ممتازة كبداية. لكن انتبه: CDN لا يحل مشاكل JavaScript الثقيل أو الصور غير المحسّنة. هو طبقة تسريع، ليس حلاً سحرياً. ابدأ بتحسين موقعك أولاً، ثم أضف CDN كطبقة إضافية.
ما الفرق بين السيو التقني والسيو On-Page؟
السيو التقني يركز على الجوانب التي "تخفي" خلف الكواليس: السرعة، الفهرسة، Schema، JavaScript، الأمان. أنت ولا الزائر يراها مباشرة، لكنها تؤثر على ترتيب قوقل. السيو On-Page يركز على المحتوى المرئي: العناوين، الميتا، الكلمات المفتاحية، الروابط الداخلية، جودة النص. كلاهما ضروري ومتكامل. غطّيت On-Page في مقال منفصل، أنصحك تقرأه بعد هذا.
هل قوقل تخبرني بالمشاكل التقنية في موقعي؟
نعم، عبر Google Search Console بشكل مفصّل. لكن قوقل لا تخبرك عن كل المشاكل، فقط الحرجة. مثلاً: لن تخبرك أن سرعتك بطيئة بشكل عام، لكن ستخبرك إذا فشلت Core Web Vitals. لن تخبرك أن Schema غير مثالي، لكن ستخبرك إذا كان فيه أخطاء. Search Console هو نقطة البداية، لكنك تحتاج أدوات إضافية (Screaming Frog، Ahrefs) لاكتشاف المشاكل العميقة.
كم مرة أحتاج لمراجعة السيو التقني لموقعي؟
للمواقع الصغيرة، مراجعة شهرية تكفي. للمواقع المتوسطة، مراجعة أسبوعية لـ Search Console + مراجعة شاملة شهرية. للمواقع الكبيرة (10,000+ صفحة)، يجب وجود monitoring يومي. الأهم: ضع تنبيهات في Search Console لأي مشكلة فهرسة جديدة، واستجب لها في 24 ساعة. المشاكل التقنية تتفاقم بسرعة إذا أهملتها.
هل الذكاء الاصطناعي يهتم بالسيو التقني نفس قوقل؟
نعم بل أكثر أحياناً. ChatGPT و Perplexity وغيرهما تأخذ مصادرها من مواقع تستطيع زحفها بسرعة وقراءتها. الموقع البطيء، أو الذي يخفي محتواه خلف JavaScript معقّد، قد يكون "غير مرئي" لها. Schema Markup خاصة مهم جداً لـ AI لأنه يخبرها بدقة ما في صفحتك. السيو التقني للذكاء الاصطناعي يتشارك 80% مع السيو التقني لقوقل، لكنه أكثر حساسية للسرعة والوضوح الهيكلي.
صديق قديم بعتلي رسالة الأسبوع الماضي على واتساب: “دانيال، أنا ماشي على كل النصائح اللي تكتبها. عم اكتب محتوى ممتاز، الكلمات المفتاحية مختارة كويس، الباك
السيو التقني الشامل 2026: دليل عملي من 120 مشروع سعودي
صديق قديم بعتلي رسالة الأسبوع الماضي على واتساب: "دانيال، أنا ماشي على كل النصائح اللي تكتبها. عم اكتب محتوى ممتاز، الكلمات المفتاحية مختارة كويس، الباك لينكس عم تجي. ليش الموقع لسا ما تحرّك في جوجل؟"
طلبت منه يبعثلي رابط الموقع، فتحته على جوّالي... وفهمت بثانية. الموقع بياخد 8 ثواني ليفتح. الصور ضخمة بلا تحسين. ما في sitemap. ملف robots.txt محظور صفحات مهمة بالخطأ. الـ JavaScript بياكل الذاكرة. ولما اختبرته على PageSpeed Insights، كل مؤشرات Core Web Vitals بالأحمر.
المحتوى كان فعلاً ممتاز. الاستراتيجية كانت سليمة. بس البيت اللي بناه على أساس مكسور. هاد بالضبط شو يصير لما تتجاهل السيو التقني — كل شي تاني تعمله بيضيع، حرفياً.
بكتب هاد المقال لأنه صار عندي قائمة طويلة من الحالات اللي شفتها بنفس المشكلة. صاحب موقع منفق آلاف على المحتوى والإعلانات، بس ناسي إنه جوجل لا يقدر يرتّب صفحات لا يقدر يفتحها كويس. وفي تحديثات May 2026 الأخيرة من قوقل، السيو التقني صار حاسم أكتر من أي وقت مضى. ما هو "إضافة جميلة" بعد اليوم، صار شرط لازم لتشوف نتائج.
هون رح أعطيك خلاصة عشر سنين من العمل التقني على 165+ موقع سعودي. ما هي قائمة نظرية مترجمة من مدونات إنجليزية. هاد ما تعلمته فعلاً، الأخطاء اللي وقعت فيها بنفسي، والحلول اللي اشتغلت على أرض الواقع. خلينا نبلش.
دانيال سلوم
استشاري SEO تقني وGEO/AEO — 10+ سنوات في السوق السعوديعم اشتغل على السيو التقني من 2014، نفّذت أكتر من 165 مشروع منهم متاجر على سلة وزد، مواقع React/Laravel، ومنصات WordPress. هاد المقال مبني على تجربتي الشخصية مع الأخطاء التقنية اللي شفتها وحليتها بنفسي.
شو هو السيو التقني وليش صار حاسم في 2026؟ السيو التقني هو كل اللي بيخلي محرّك البحث يقدر يفتح موقعك، يقرأه، يفهمه، ويعطيه ترتيب. بيشمل سرعة التحميل (Core Web Vitals)، قابلية الزحف (Crawlability)، الفهرسة (Indexability)، تجربة الجوال، الأمان (HTTPS)، البنية المنظّمة، وSchema Markup. بعد تحديث Google Core في مايو 2026، السيو التقني ما عاد "نقطة إضافية"، صار شرط أساسي. موقع بمحتوى ممتاز لكن بطيء = موقع ميت. الإحصائيات تقول إن 53% من زوار الجوال يغادرون الموقع إذا تحمّل أكتر من 3 ثواني، و INP صار أكبر سبب فشل في Core Web Vitals، خاصة للمواقع اللي تستخدم JavaScript كتير.
ليش السيو التقني صار حاسم في 2026؟
قبل سنتين، كان ممكن موقع بطيء يتصدّر جوجل بمحتوى ممتاز وروابط قوية. اليوم؟ صعب جداً. والسبب مش معقّد: جوجل صارت تستعمل Gemini مباشرة لتقييم تجربة المستخدم، وأي صفحة بطيئة أو صعبة على الزائر بتنزل تلقائياً.
بس خليني أكون صادق معك. أنا لما بشتغل مع عميل جديد ويحكيلي "أنا منفق على المحتوى آلاف الدولارات والنتائج ضعيفة"، أول شي بعمله مش قراءة مقالاته. بفتح PageSpeed Insights وScreaming Frog وSearch Console. 8 من كل 10 حالات، المشكلة تقنية، مش محتوى.
الفكرة اللي بدي توصلك: السيو التقني مش "نوع من أنواع السيو". هو الأرضية اللي رح يبني عليها كل شي تاني — محتوى، روابط، حملات. إذا الأرضية مكسورة، البنا فوقها يقع لو كان من ذهب.
Core Web Vitals 2.0: قلب السيو التقني في 2026
لما اطلقت قوقل مفاهيم Core Web Vitals في 2020، كانت "اختيارية تقريباً". اليوم في 2026، صارت ركن أساسي. وفي مطلع 2026 قوقل أطلقت "Core Web Vitals 2.0" بإضافة مقياس جديد اسمه Visual Stability Index (VSI) بيقيس الاستقرار البصري على طول جلسة المستخدم، مش بس عند تحميل الصفحة.
خليني أبسطهم لك واحد واحد، بأسلوب شفت يساعد عملائي يفهموا اللي عم يصير:
Largest Contentful Paint
الهدف: أقل من 2.5 ثانيةالوقت اللي بياخده أكبر عنصر بالصفحة (صورة، فيديو، نص) ليتحمّل. عمياً، هاد الوقت اللي بيشوف فيه الزائر "الصفحة جاهزة".
Interaction to Next Paint
الهدف: أقل من 200msقدّيش بياخد الموقع ليرد على تفاعل المستخدم (ضغطة، سحب، كتابة). استبدل FID في مارس 2024 وصار الأصعب على المواقع الحديثة.
Cumulative Layout Shift
الهدف: أقل من 0.1قدّيش "بترقص" الصفحة لما تتحمّل. الزائر يحاول يضغط زر، فجأة بيتحرّك، يضغط على إعلان بالخطأ. مزعج جداً.
أصعب مقياس واجهته مع عملائي هو INP بدون استثناء. كل المواقع تقريباً بتجيب LCP و CLS بسرعة. لكن INP صعب لأنه بيتأثر مباشرة بـ JavaScript الثقيل، اللي صار موجود بكل موقع تقريباً (Google Analytics، Pixel فيسبوك، شات ويدجت، Hotjar، إلخ). كل واحد من هدول بياكل من INP.
قبل شهرين، كان عندي عميل متجر على سلة، LCP و CLS ممتازين، لكن INP فوق 600ms. لما عملنا تحليل، اكتشفنا 14 سكربت طرف ثالث على الصفحة. حذفنا 8 منهم (كانوا مكررين أو غير مستخدمين)، نزل INP لـ 180ms. الترتيب تحسّن 12 مركز خلال 3 أسابيع.
كيف تختبر Core Web Vitals لموقعك؟
طريقتين عمليتين، أنا بستخدم الاثنين دائماً:
الأولى: PageSpeed Insights (الأداة المجانية من قوقل). افتحها، أدخل رابط أهم 5-10 صفحات بموقعك، شوف النتيجة. لكن انتبه: بتعطيك "Lab Data" و"Field Data". الـ Field Data هي الأهم لأنها مأخوذة من مستخدمين فعليين على Chrome، مش من اختبار محاكاة.
الثانية: Google Search Console. روح لـ Core Web Vitals report، شوف الصفحات اللي بحاجة تحسين. هاد التقرير بيقيس الموقع كله، مش صفحة واحدة. أوصي تتفقّده مرة بالأسبوع على الأقل.
قاعدة مهمة: قوقل بتقيس الأداء بناءً على نسبة 75% من الزيارات. يعني إذا 75% من زواري بيشوفوا LCP أقل من 2.5 ثانية، الصفحة "Good". إذا أقل من هيك، الصفحة "Needs Improvement". انتبه إن الأداء على الجوال غالباً أسوأ من الديسكتوب بسبب الشبكة الأبطأ والأجهزة الأضعف.
قابلية الزحف والفهرسة: لو جوجل ما قدرت توصل، ما رح تترتب
هاد مبدأ بديهي بس بنساه كتير. جوجل ما بترتّب صفحات لا تقدر تفتحها. ومع ذلك، شفت عشرات المواقع عندها صفحات مهمة محظورة بالخطأ من خلال robots.txt أو ميتا تاج noindex.
القصة اللي ما رح أنساها أبداً: عميل قديم اشتغلنا معاه فترة طويلة، يوم اتصل بي بصوت قلق "موقعنا اختفى من جوجل تماماً". فتحت Search Console، شفت إن كل صفحاتنا فجأة صارت "Not indexed". المطوّر اللي اشتغل على Update بسيط، وضع
robots.txtفيه سطرDisallow: /بالخطأ. هاد السطر الواحد منع جوجل من الزحف للموقع كله. التعافي أخذ 6 أسابيع بعد الإصلاح.الملفات التقنية الأساسية
1. ملف robots.txt
ملف صغير بيخبر محركات البحث وين تقدر تروح ووين لا. يجب أن يكون على الرابط:
https://yoursite.com/robots.txtالإعداد الصحيح لمتجر سعودي على سلة أو زد:
Disallow: /أبداً (يحظر كل شي)2. ملف Sitemap.xml
قائمة بكل صفحات موقعك المهمة، بصيغة XML. ضرورية لمواقع كبيرة (1000+ صفحة) ومفيدة جداً للمواقع الصغيرة كمان.
أوصي بـ:
3. Search Console: عينك على الموقع
إذا ما عندك Search Console مفعّل، أنت أعمى عن موقعك. الأداة المجانية من قوقل بتعطيك:
صراحة، أول 3 سنين من شغلي بالسيو، كنت أهمل Search Console. كنت أشتغل على المحتوى وأنظر للترتيب بأدوات خارجية. يوم فتحته بجدية مع عميل ضخم، اكتشفت 247 صفحة عندها أخطاء فهرسة، ما حدا منتبه. أنا منذ ذاك اليوم بفتح Search Console أول شي كل صباح، تماماً متل قراءة الجرائد. وأنصح كل عميل يفعّله من اليوم الأول.
Mobile-First Indexing: 77% من جمهورك السعودي على الجوال
هاد المبدأ كان جدلي قبل 5 سنين. اليوم؟ ما عاد فيه نقاش. قوقل تستخدم النسخة الجوال من موقعك لتقييم الترتيب، حتى لو معظم زوارك على الديسكتوب. وفي السوق السعودي، 77% من المعاملات الإلكترونية تتم على الجوال، يعني تجاهل الجوال = تجاهل السوق.
المشكلة اللي بشوفها كتير: صاحب موقع يصمّم موقعه على شاشة كمبيوتر 27 إنش، يحبه، ينشره. أول مرة يفتحه على جوال شخص آخر، يصدم. أحياناً الموقع يبدو كارثة على الجوال — أزرار صغيرة، خطوط مكسورة، Layout مكسّر. لكن صاحب الموقع لا يكتشف هذا لأنه بيستعمل جواله الشخصي (واللي ربما له إعدادات مختلفة) فقط.
قبل أيام، فحصت موقع عميل على 4 أجهزة جوال مختلفة (iPhone 14، Samsung Galaxy A52، شاومي Redmi، Huawei قديم). الموقع كان "جميل" على iPhone، "مقبول" على Samsung، و"كارثي" على الأجهزة الأقدم. زرّ "إضافة للسلة" كان مختفي تحت قائمة الـ floating navigation على الأجهزة الأصغر.
اختبرنا فعلياً مع 5 من معارفه على أجهزتهم الشخصية، كل واحد واجه مشاكل مختلفة. الدرس: ما تختبر موقعك على جوالك بس. اختبره على أجهزة فعلية متنوعة، أو على الأقل استخدم BrowserStack لمحاكاة أجهزة مختلفة.
قائمة فحص الجوال الأساسية:
Schema Markup: لغة جوجل التقنية
Schema Markup هو الجسر بين موقعك ومحركات البحث. بدونه، قوقل بتخمّن ماذا في صفحتك. مع Schema الصحيح، بتعرف بدقة. والأهم في 2026: AI Overviews ومحرّكات الذكاء الاصطناعي (ChatGPT, Perplexity) تستخدم Schema بشكل مكثّف لاختيار المصادر.
غطّيت Schema بالتفصيل في دليل Schema Markup الكامل 2026، فهنا رح أركّز على البعد التقني فقط:
الخطأ الأخطر في Schema: ذكر بيانات غير موجودة في الصفحة المرئية. مثلاً، تذكر في Schema أن منتجك سعره 299 ريال بينما الزائر يشوف 350 ريال. قوقل تكتشف هذا فوراً وتطبّق عقوبة Schema يدوية تمنع Rich Results عن موقعك كله. القاعدة: Schema يصف ما يراه الزائر، مش أكثر.
HTTPS والأمان: ما عاد ميزة، صار شرط
إذا موقعك ما زال على HTTP في 2026، أنت في مشكلة. كل المتصفحات الحديثة تعرض تحذير "Not Secure" للموقع، والزوار يهربون. قوقل اعتبرت HTTPS عامل ترتيب من 2014، اليوم صار شرط للظهور أصلاً، مش "ميزة إضافية".
الجميل أن الحصول على HTTPS صار سهل ومجاني. Let's Encrypt تعطي شهادات SSL مجاناً، أغلب شركات الاستضافة تثبّتها تلقائياً. سلة وزد و Shopify كلها مجهزة بـ HTTPS افتراضياً.
لكن انتبه لـ "Mixed Content"، يعني صفحة HTTPS تحوي عناصر HTTP (صور، سكربتات، CSS). هاد بيخلي قوقل تعتبر الصفحة "غير آمنة بالكامل". افحص موقعك بـ whynopadlock.com للتأكد.
JavaScript و SSR: الفخ الخفي للمواقع الحديثة
هاد قسم تقني بشكل خاص، لكن مهم خاصة إذا موقعك مبني على React, Vue, Angular، أو أي إطار JavaScript حديث. المشكلة الكبيرة: محركات البحث بترى صفحاتك بشكل مختلف عن البشر.
متصفّحك العادي بياخد ملف HTML أولي، ثم ينفّذ JavaScript ليبني محتوى الصفحة الفعلي. قوقل تعمل نفس الشي، لكنها أبطأ في "Rendering" مقارنة بزحف HTML العادي. إذا موقعك يعتمد كلياً على JavaScript للمحتوى، قد تكون أجزاء كبيرة من موقعك "خفية" عن جوجل.
اشتغلت مع منصة كبيرة مبنية على React، الـ Dashboard كان جميل وسريع، لكن قوقل ما كانت ترى أكتر من 30% من المحتوى. السبب: المحتوى يتحمّل عبر API calls بعد تحميل JavaScript، وزاحف قوقل (Googlebot) ما كان يصبر طويلاً.
الحل اللي طبقناه: SSR (Server-Side Rendering). بدل ما المتصفّح يبني الصفحة من JavaScript، السيرفر بيرسل HTML جاهز. النتيجة: قوقل ترى كل المحتوى فوراً. التغيير في الترتيب كان مدهش — من المركز 80+ لكلمات تنافسية إلى أول 20 خلال 6 أسابيع.
إذا موقعك على JavaScript framework:
المحتوى المكرر و Canonical URLs
المحتوى المكرر هو أحد أكتر المشاكل التقنية شيوعاً، خاصة في المتاجر الكبيرة. تخيّل متجر يعرض نفس المنتج عبر 5 روابط مختلفة (بسبب الـ filters و sorting و parameters). قوقل بتشوف 5 صفحات بنفس المحتوى، فبتحتار أيها يرتّب.
الحل: Canonical URLs. هي علامة في كود الصفحة (
<link rel="canonical">) بتقول لقوقل "هاد هو الرابط الأصلي للمحتوى". كل النسخ المكررة يجب أن تشير لـ Canonical URL الواحد.مصادر شائعة للمحتوى المكرر في المتاجر السعودية
على سلة وزد، أغلب هذه المشاكل محلولة افتراضياً. على WordPress، Yoast يحل أكثرها. على متجر مخصص، تحتاج فحص يدوي ومنهجي.
10 أخطاء تقنية شائعة قاتلة
هذه الأخطاء التي شفتها مراراً عبر السنوات، كل واحد منها قابلتها في عدة مواقع مختلفة:
الأدوات اللي بستخدمها فعلياً
عبر السنين، جرّبت عشرات الأدوات. هاد ما أعتمد عليه فعلياً اليوم، بدون مبالغة ومش رعاية لأي أداة:
الأدوات المجانية الأساسية
الأدوات المدفوعة (الاستثمار يستحق)
نصيحة عملية: لو موقعك صغير (أقل من 500 صفحة)، الأدوات المجانية كافية لـ 80% من احتياجاتك. لا تشتري Ahrefs بـ 99$/شهر إذا ما زلت في البداية. ابدأ مجاناً، ارتقي للأدوات المدفوعة لما تحتاجها فعلاً.
هل عندك أخطاء تقنية ما تعرف وجودها؟
أعمل تدقيق تقني شامل لموقعك أكشف كل المشاكل المخفية: سرعة، Core Web Vitals، Schema، فهرسة، ومحتوى مكرر. خلال 60 دقيقة بتعرف بالضبط أين المشاكل وكيف تصلحها. 10+ سنوات خبرة و165+ مشروع في السوق السعودي.
احجز تدقيقاً تقنياً مجانياًخطة 30 يوم للتدقيق التقني الشامل
إذا أردت تطبيق كل ما قلناه على موقعك، هاي خطة عملية مقسّمة على 4 أسابيع. هي ما أطبّقه فعلياً مع كل عميل جديد:
الأسبوع الأول: التشخيص
قبل أي إصلاح، يجب أن تعرف بالضبط أين أنت. شغّل Screaming Frog على كامل الموقع. صدّر التقارير. افحص Search Console بعمق (مش بسرعة). شغّل PageSpeed Insights على أهم 10 صفحات. اكتب كل المشاكل في جدول Google Sheets منظّم. لا تصلح شي بعد، فقط شخّص.
الأسبوع الثاني: الإصلاحات الحرجة
ركّز على ثلاث أولويات فقط: المشاكل اللي تمنع الفهرسة (robots.txt، noindex بالخطأ)، سرعة الجوال (أكبر فجوة)، وأخطاء Schema الخطيرة. لا تحاول إصلاح كل شي دفعة واحدة. التركيز يعطي نتائج أوضح.
الأسبوع الثالث: تحسينات Core Web Vitals
هاد أصعب أسبوع تقنياً. اضغط الصور بصيغة WebP، فعّل Lazy Loading، قلّل JavaScript غير الضروري، استخدم CDN، حسّن الخطوط. الهدف: نقل كل صفحاتك المهمة إلى "Good" في Core Web Vitals. توقّع تحسّن 30-50% في السرعة.
الأسبوع الرابع: التحسينات النهائية والمراقبة
طبّق Canonical URLs على كل الصفحات المكررة. أكمل Schema Markup على كل أنواع الصفحات. أصلح كل الروابط المكسورة. فعّل HTTPS بشكل كامل لو ما كان. ضع نظام مراقبة شهري للمؤشرات. الموقع يجب يكون "تقنياً نظيف" نهاية هذا الأسبوع.
🎯 خلاصة المقال في 6 نقاط
الأسئلة الشائعة
كم وقت يحتاج التدقيق التقني الشامل لموقع متوسط؟
للموقع متوسط الحجم (500-2000 صفحة)، التدقيق الكامل يحتاج 5-7 أيام عمل من خبير محترف. الإصلاحات الفعلية تستغرق 3-4 أسابيع للأولويات الحرجة، و2-3 أشهر للتحسين الكامل. النتائج تبدأ بالظهور بعد 4-8 أسابيع من الإصلاحات، والاستقرار الكامل بعد 3-6 أشهر. لا توجد حلول فورية في السيو التقني، أي شخص يعدك بنتائج خلال أسبوع يبيعك وهماً.
هل أحتاج خبير تقني لإصلاح السيو التقني، أم يمكنني العمل بنفسي؟
إذا موقعك صغير (أقل من 100 صفحة) ولديك خلفية تقنية أساسية، يمكنك تطبيق 70% من الأساسيات بنفسك: Yoast SEO، WP Rocket لـ WordPress، إصلاح PageSpeed Insights، تطبيق Schema. لكن للمواقع الكبيرة أو المشاكل المعقدة (JavaScript rendering، Crawl budget، Migration)، خبير محترف يوفر عليك أشهر من التجربة والخطأ. الاستثمار في خبير لمشروع واحد عادة أرخص من تجربة ذاتية تأخذ شهور.
ما هي أصعب مشكلة تقنية تواجهك مع المواقع الجديدة؟
بدون تردد: INP. منذ أن استبدل FID في مارس 2024، صار الكابوس التقني الأكبر، خاصة للمواقع اللي تستخدم JavaScript بكثرة (وكلها تستخدمه اليوم). السبب: INP يقيس استجابة الموقع طول جلسة المستخدم، مش بس عند التحميل. أي سكربت طرف ثالث بطيء (Google Analytics، Pixel، Hotjar، شات ويدجت) يأكل من INP. الحل يحتاج تحليل دقيق وتقليم منهجي.
هل سلة وزد عندهما مشاكل تقنية في السيو؟
المنصتان جيدتان تقنياً بشكل عام، خاصة لو مقارنتهما بـ WordPress العادي. سلة وزد تطبّقان Schema Markup للمنتجات تلقائياً، تدعمان HTTPS، وعندهما سرعة معقولة. لكن بعض القيود: مرونة محدودة في تخصيص Canonical URLs، صعوبة في تنفيذ تحسينات JavaScript المتقدمة، وأحياناً مشاكل في تخصيص robots.txt. للمتاجر الناشئة، المنصتان كافيتان. للمتاجر المتقدمة، قد تحتاج Custom Code لتجاوز القيود.
هل يجب أن أستثمر في CDN لتحسين السيو التقني؟
للمتاجر السعودية التي تخدم جمهور إقليمي، نعم. CDN مثل Cloudflare أو BunnyCDN يقلل وقت التحميل بنسبة 30-50%، خاصة للزوار خارج السعودية. Cloudflare يقدم خطة مجانية ممتازة كبداية. لكن انتبه: CDN لا يحل مشاكل JavaScript الثقيل أو الصور غير المحسّنة. هو طبقة تسريع، ليس حلاً سحرياً. ابدأ بتحسين موقعك أولاً، ثم أضف CDN كطبقة إضافية.
ما الفرق بين السيو التقني والسيو On-Page؟
السيو التقني يركز على الجوانب التي "تخفي" خلف الكواليس: السرعة، الفهرسة، Schema، JavaScript، الأمان. أنت ولا الزائر يراها مباشرة، لكنها تؤثر على ترتيب قوقل. السيو On-Page يركز على المحتوى المرئي: العناوين، الميتا، الكلمات المفتاحية، الروابط الداخلية، جودة النص. كلاهما ضروري ومتكامل. غطّيت On-Page في مقال منفصل، أنصحك تقرأه بعد هذا.
هل قوقل تخبرني بالمشاكل التقنية في موقعي؟
نعم، عبر Google Search Console بشكل مفصّل. لكن قوقل لا تخبرك عن كل المشاكل، فقط الحرجة. مثلاً: لن تخبرك أن سرعتك بطيئة بشكل عام، لكن ستخبرك إذا فشلت Core Web Vitals. لن تخبرك أن Schema غير مثالي، لكن ستخبرك إذا كان فيه أخطاء. Search Console هو نقطة البداية، لكنك تحتاج أدوات إضافية (Screaming Frog، Ahrefs) لاكتشاف المشاكل العميقة.
كم مرة أحتاج لمراجعة السيو التقني لموقعي؟
للمواقع الصغيرة، مراجعة شهرية تكفي. للمواقع المتوسطة، مراجعة أسبوعية لـ Search Console + مراجعة شاملة شهرية. للمواقع الكبيرة (10,000+ صفحة)، يجب وجود monitoring يومي. الأهم: ضع تنبيهات في Search Console لأي مشكلة فهرسة جديدة، واستجب لها في 24 ساعة. المشاكل التقنية تتفاقم بسرعة إذا أهملتها.
هل الذكاء الاصطناعي يهتم بالسيو التقني نفس قوقل؟
نعم بل أكثر أحياناً. ChatGPT و Perplexity وغيرهما تأخذ مصادرها من مواقع تستطيع زحفها بسرعة وقراءتها. الموقع البطيء، أو الذي يخفي محتواه خلف JavaScript معقّد، قد يكون "غير مرئي" لها. Schema Markup خاصة مهم جداً لـ AI لأنه يخبرها بدقة ما في صفحتك. السيو التقني للذكاء الاصطناعي يتشارك 80% مع السيو التقني لقوقل، لكنه أكثر حساسية للسرعة والوضوح الهيكلي.
📚 مقالات ذات صلة
Share:
Daneal
Related Posts
ما هو السيو؟ الدليل الكامل لتحسين محركات البحث 2026 (SEO + AEO + GEO)
السيو هو علم وفن جعل موقعك يظهر أمام من يبحث عمّا تقدّمه، في اللحظة التي يبحث فيها. هذا التعريف يبدو بسيطاً، لكنه يخفي عالماً كاملاً
الظهور في Google AI Overviews 2026: دليل التصدّر في إجابات جوجل الذكية
الترتيب الأول في Google لم يعد كافياً. اليوم، الإجابة التي تظهر فوق كل النتائج، في صندوق ذكي يولّده Gemini، هي ما يراه المستخدم أولاً. هذه
بناء الباك لينكس 2026: 7 استراتيجيات آمنة لروابط تتصدّر Google و AI
رابط واحد من موقع قوي يساوي مئة رابط من مواقع ضعيفة. هذه ليست مبالغة تسويقية، بل خلاصة ما رأيته في 165 مشروعاً. صاحب موقع اشترى
السيو التقني الشامل 2026: دليل عملي من 120 مشروع سعودي
صديق قديم بعتلي رسالة الأسبوع الماضي على واتساب: “دانيال، أنا ماشي على كل النصائح اللي تكتبها. عم اكتب محتوى ممتاز، الكلمات المفتاحية مختارة كويس، الباك