I've migrated blogs from subdomains to subdirectories more times than I can count. I've also done the reverse -- moved entire app sections onto subdomains when the architecture demanded it. And here's what I've learned after years of watching the rankings shake out: the answer isn't as simple as either camp wants you to believe.

Google's official stance hasn't changed much -- they say they can handle both. But what Google says and what actually happens in the SERPs are two different things. This guide is for engineers and technical decision-makers who need to make the call and live with the consequences. We'll cover the real SEO mechanics, the infrastructure implications, and the data that actually matters in 2026.

جدول المحتويات

Subdomain vs Subdirectory SEO: The Engineering Guide for 2026

الفرق الأساسي

دعونا نخرج الأساسيات من الطريق. النطاق الفرعي هو اسم مضيف منفصل:

blog.example.com
shop.example.com
app.example.com

الدليل الفرعي (يُسمى أيضاً المجلد الفرعي) يعيش تحت نطاقك الرئيسي:

example.com/blog
example.com/shop
example.com/app

من منظور DNS، النطاقات الفرعية هي مضيفات مختلفة تماماً. يمكنها الإشارة إلى خوادم مختلفة وعناوين IP مختلفة وقارات مختلفة. الدليل الفرعي هو فقط مسار على نفس المضيف.

إليك الشيء الذي تتجاهله معظم مقالات SEO: من منظور المتصفح وHTTP، هذه أشياء مختلفة بشكل أساسي. ملفات تعريف الارتباط و CORS وسياسات الأمان وبشكل حاسم -- كيفية تخصيص ميزانية الزحف من قبل محركات البحث تختلف بين النهجين.

كيفية معاملة محركات البحث لهما بشكل مختلف

على الرغم من طمأنات Google، تتعامل أنظمتهم الخاصة مع النطاقات الفرعية والدلائل الفرعية بطرق مختلفة في عدة طرق قابلة للقياس:

  • ميزانية الزحف يتم تخصيصها لكل مضيف. يحصل blog.example.com على ميزانية زحف منفصلة عن example.com.
  • عامل Site: يعاملهما بشكل منفصل. حاول site:blog.example.com مقابل site:example.com/blog -- ستشهد سلوكاً فهرسياً مختلفاً.
  • Google Search Console يتطلب خصائص منفصلة للنطاقات الفرعية (على الرغم من أن خصائص المجال الآن تجميعها).
  • حقوق الارتباط تتدفق بشكل مختلف. الرابط إلى example.com/blog/great-post يعزز مباشرة النطاق الجذر. الرابط إلى blog.example.com/great-post يعزز... النطاق الفرعي.

ما يقوله Google فعلاً (وما لا يقولونه)

قال John Mueller مراراً وتكراراً أن Google يمكنها التعامل مع الاثنين وتعاملهما بالتساوي تقريباً. ها هي الاقتباس الدقيق الذي يتم نشره في كل مكان:

"Google Web Search بخير مع استخدام النطاقات الفرعية أو الدلائل الفرعية."

لكن ها هو ما لا يقولونه: "متساوياً" لا يعني "متطابقاً". توثيق Google الخاص حول نقل الموقع يعترف بأن النقل من نطاق فرعي إلى دليل فرعي (أو العكس) يُعتبر نقل موقع -- نفس الفئة مثل الانتقال إلى نطاق جديد تماماً.

فكر في ذلك للحظة. تتعامل Google مع blog.example.com → example.com/blog بنفس الأهمية مثل oldsite.com → newsite.com. وحده هذا يخبرك أن هذه ليست متكافئة في أنظمة Google.

اعتباراً من 2025-2026، يجعل نظام محتوى Google المفيد وإشارات مستوى الموقع هذا أكثر أهمية. يبدو أن تقييمات جودة مستوى الموقع محصورة على مستوى اسم المضيف في كثير من الحالات. إذا كان موقعك الرئيسي يحتوي على إشارات E-E-A-T قوية لكن مدونتك الفرعية لا تملك، فقد تترك قيمة على الطاولة.

حالة SEO لصالح الدلائل الفرعية

دعني أكون مباشراً: بالنسبة لمعظم المواقع، الدلائل الفرعية هي الخيار الأفضل لـ SEO. وإليك السبب.

توحيد سلطة المجال

كل رابط خلفي يشير إلى أي صفحة على example.com -- سواء كانت /blog/post أو /products/widget أو /about -- يساهم في السلطة الإجمالية لـ example.com. هذا تبسيط لكيفية عمل PageRank، لكنه صحيح بشكل اتجاهي.

مع النطاقات الفرعية، تقوم بتقسيم تلك السلطة. قد يكون لموقعك الرئيسي درجة نطاق 65، لكن قد يكون blog.example.com جالساً عند 25 لأنه يُعامل كنطاق منفصل لحسابات رسم البيان للروابط.

رأيت هذا يحدث مراراً وتكراراً. كان لديها عميل SaaS مدونة على نطاق فرعي لمدة ثلاث سنوات. عندما هاجرنا إلى /blog، زيادة حركة المرور العضوية لتلك المشاركات نفسها 72٪ على مدى 90 يوماً. المحتوى لم يتغير. الربط الداخلي تغير بالكاد. ما تغير هو أن تلك المشاركات يمكنها الآن الاستفادة من السلطة الموجودة للنطاق.

ربط داخلي مبسط

الروابط الداخلية من example.com/pricing إلى example.com/blog/post هي روابط من نفس المضيف. إنها تمرر الحد الأقصى من حقوق الارتباط. الروابط الداخلية من example.com/pricing إلى blog.example.com/post هي تقنياً روابط عبر المضيف. بينما قد تفهم Google العلاقة، الإشارة ليست نظيفة.

كفاءة الزحف

مع كل شيء تحت مضيف واحد، يمكن لـ Googlebot اكتشاف واستكشاف المحتوى الخاص بك بكفاءة أكبر. ملف robots.txt واحد. هيكل خريطة موقع واحد. مجموعة ميزانية زحف واحدة. بالنسبة للمواقع الكبيرة بآلاف الصفحات، هذا يهم أكثر مما تعتقد.

بيانات أداء المحتوى

وجدت دراسة Ahrefs 2024 التي حللت 10000+ موقع أن صفحات الدلائل الفرعية تفوقت صفحات النطاق الفرعي المكافئة 60٪ من الوقت، مع التحكم في جودة المحتوى والروابط الخلفية. أظهر تحليل مشابه من Semrush في أوائل 2025 أن مشاركات مدونات الدليل الفرعي كان لديها، في المتوسط، 20-30٪ من حركة المرور العضوية أكثر من مشاركات النطاق الفرعي المقارنة.

هذه ليست تأثيرات صغيرة. إنها جوهرية بما يكفي للتأثير على قرارات بنيتك.

Subdomain vs Subdirectory SEO: The Engineering Guide for 2026 - architecture

متى تكون النطاقات الفرعية منطقية من ناحية الهندسة

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

تطبيقات مختلفة تماماً

إذا كان app.example.com عبارة عن React SPA خلف المصادقة، فهو لا يحتاج إلى مشاركة هيكل URL مع موقعك التسويقي. لا توجد فائدة SEO لوجود لوحة معلومات في example.com/app -- يجب ألا يفهرس Google لها على أي حال.

أكوام التكنولوجيا المختلفة التي لا يمكن مشاركة البنية الأساسية

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

الدولية على نطاق واسع

بالنسبة للخبرات الإقليمية المنفصلة تماماً -- محتوى مختلف وفريق مختلف وحالات CMS مختلفة -- يمكن للنطاقات الفرعية مثل de.example.com أو jp.example.com أن تحقق معنى تشغيلياً. على الرغم من أنني لا أزال أجادل بأن example.com/de/ أفضل لـ SEO في معظم الحالات.

عزل محتوى ينتجه المستخدم

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

عامل دليل فرعي نطاق فرعي
توحيد حقوق الارتباط ✅ مشترك عبر جميع المسارات ❌ منفصل لكل اسم مضيف
ميزانية الزحف ✅ مجموعة واحدة ❌ تقسيم عبر المضيفات
تعقيد الإعداد ✅ بسيط ✅ بسيط
مرونة كومة التكنولوجيا ❌ يتطلب وكيل عكسي لأكوام متعددة ✅ كل نطاق فرعي يمكن أن يكون مستقلاً
Google Search Console ✅ خاصية واحدة ⚠️ يتطلب خصائص منفصلة
عزل الأمان ❌ أصل مشترك ✅ أصل منفصل
إشارات جودة مستوى الموقع ✅ إشارات إيجابية مشتركة ⚠️ قد لا ترث إشارات النطاق الأب
بساطة التحليلات ✅ نفس الخاصية وتتبع سهل ⚠️ يتطلب تتبع عبر النطاقات
استقلال النشر ❌ النشرات المزدوجة ✅ النشرات المستقلة

بيانات الترحيل الحقيقية: ما يحدث عند التبديل

دعني أشارك بعض الأنماط التي رأيتها من ترحيل النطاق الفرعي إلى الدليل الفرعي الفعلي:

ترحيل المدونة SaaS

انتقلت شركة B2B SaaS بمدونتهم من blog.company.com إلى company.com/blog في الربع الثاني من 2024. كانت المدونة تحتوي على حوالي 400 منشور وكانت تولد حوالي 15000 جلسة عضوية شهرياً.

  • الأسبوع 1-2: انخفضت حركة المرور بحوالي 15٪ (اضطراب متوقع أثناء الترحيل)
  • الأسبوع 3-4: تعافي إلى مستويات ما قبل الترحيل
  • الشهر 2-3: تسلق مستمر، وصولاً إلى 120٪ من حركة المرور السابقة للترحيل
  • الشهر 6: استقر عند ~170٪ من حركة المرور السابقة للترحيل

كانت عمليات إعادة التوجيه 301 نظيفة. كل blog.company.com/slug أعادة توجيه إلى company.com/blog/slug. تم تحديث العلامات الأساسية. تم استخدام أداة تغيير العنوان في Google Search Console. ومع ذلك، كانت تلك الأسابيع الأسبوعين الأولين عصيبة.

نقل وثائق التجارة الإلكترونية

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

النتائج: تحسنت متوسط موضع الترتيب لصفحات التوثيق بمقدار 4.2 مركز في غضون 60 يوماً. بدأت الصفحات التي كانت تحوم على الصفحة 2 تظهر على الصفحة 1 لاستعلامات API التنافسية.

الذي ذهب بشكل خاطئ

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

الدرس: لا تدمج بشكل أعمى محتوى منخفض الجودة في هيكل URL للنطاق الرئيسي. جودة المحتوى مهمة مثل الهيكل.

أنماط البنية الأساسية لكل نهج

دليل فرعي مع الاستضافة أحادية الكتلة

النهج الأبسط. موقعك بالكامل -- صفحات التسويق والمدونة والوثائق -- يعمل على تطبيق أو إطار عمل واحد.

# تطبيق Next.js واحد
example.com/ → pages/index.tsx
example.com/blog → pages/blog/index.tsx
example.com/docs → pages/docs/index.tsx

هذا يعمل بشكل رائع للمواقع الأصغر. نستخدم هذا النمط بشكل متكرر لمشاريع Next.js development حيث يمكن لموقع الويب بالكامل أن يعيش في مجمع واحد.

دليل فرعي مع وكيل عكسي

هذا هو الخطوة الذكية. تشغل تطبيقات مختلفة لمسارات URL مختلفة لكنك توحدها تحت نطاق واحد باستخدام وكيل عكسي.

# إعداد وكيل عكسي Nginx
server {
    server_name example.com;
    
    # موقع التسويق الرئيسي (Next.js على Vercel)
    location / {
        proxy_pass https://main-site.vercel.app;
        proxy_set_header Host example.com;
    }
    
    # المدونة (Astro على Netlify)
    location /blog {
        proxy_pass https://blog-site.netlify.app;
        proxy_set_header Host example.com;
    }
    
    # الوثائق (Docusaurus على خادم خاص)
    location /docs {
        proxy_pass https://docs-internal.example.com;
        proxy_set_header Host example.com;
    }
}

يمكنك أيضاً القيام بذلك على الحافة مع إعادة كتابة Vercel أو Cloudflare Workers أو إعادة توجيهات Netlify:

// vercel.json rewrites
{
  "rewrites": [
    {
      "source": "/blog/:path*",
      "destination": "https://blog-site.netlify.app/:path*"
    }
  ]
}

يمنحك هذا النمط فوائد SEO من الدلائل الفرعية مع مرونة الهندسة للنشرات المستقلة. هكذا نقترب من معظم headless CMS development المشاريع حيث يعيش المحتوى في نظام واحد لكن بنية الواجهة الأمامية تمتد على عدة تطبيقات.

نطاق فرعي مع التوجيه DNS

الإعداد الأبسط من منظور البنية الأساسية:

blog.example.com → CNAME → blog-app.vercel.app
docs.example.com → CNAME → docs-app.netlify.app
app.example.com  → A    → 203.0.113.50

كل نطاق فرعي مستقل تماماً. سهل الإعداد وسهل الإدارة وسهل النشر. المقابل هو بحتة على جانب SEO.

نظام إدارة المحتوى بدون رأس وميزة الدليل الفرعي

إذا كنت تشغل إعداد CMS بدون رأس -- وفي 2026، فأنت ربما يجب أن تكون كذلك -- يتماشى نهج الدليل الفرعي بشكل طبيعي مع كيفية عمل الأطر الحديثة.

مع الأدوات مثل Astro، Next.js أو Nuxt، يمكنك جلب المحتوى من CMS الخاص بك (Sanity و Contentful و Strapi وما يحلو لك) وعرضها في أي مسار URL تريده. لا يوجد سبب تقني لكي تكون مدونتك على نطاق فرعي.

بنية الرأس النموذجية:

Contentful (CMS)
    ↓ API
Next.js (Frontend)
    ├── / (صفحات التسويق)
    ├── /blog (مدونة مدفوعة بـ CMS)
    ├── /docs (وثائق مدفوعة بـ CMS)
    └── /resources (موارد مدفوعة بـ CMS)

كل شيء يعيش تحت نطاق واحد. نشر واحد. مجموعة واحدة من تحسينات الأداء. درجة سلطة نطاق واحدة.

جمال هذا النهج هو أنك تحصل على مرونة إدارة المحتوى من CMS بدون رأس مع فوائد SEO لهيكل نطاق موحد. إنه أحد الأسباب الرئيسية التي نجعل العملاء يتحركون نحو بنى بدون رأس في Social Animal.

نمط الوكيل العكسي: الحصول على الاثنين

دعني أشرح النمط الذي نستخدمه بشكل متكرر لعملاء متوسطي الحجم والمؤسسات الذين يحتاجون إلى نشرات مستقلة وموحدة SEO.

نظرة عامة على البنية

Cloudflare (Edge)
    ├── example.com/* → Vercel (موقع التسويق Next.js)
    ├── example.com/blog/* → Vercel (مدونة Astro)
    ├── example.com/docs/* → Netlify (Docusaurus)
    └── app.example.com/* → AWS (React SPA - بدون الحاجة إلى SEO)

لاحظ أن app.example.com لا يزال نطاق فرعي. هذا مقصود -- إنه تطبيق مصرح به يجب ألا تفهرس محركات البحث له. كل شيء يحتاج إلى حقوق SEO يعيش تحت النطاق الرئيسي.

التنفيذ مع Cloudflare Workers

// Cloudflare Worker لتوجيه قائم على المسار
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    
    // مسارات الطريق /blog إلى أصل المدونة
    if (url.pathname.startsWith('/blog')) {
      const blogUrl = new URL(request.url);
      blogUrl.hostname = 'blog-origin.example.com';
      return fetch(blogUrl, {
        headers: {
          ...request.headers,
          'X-Forwarded-Host': url.hostname,
        },
      });
    }
    
    // مسارات الطريق /docs إلى أصل الوثائق
    if (url.pathname.startsWith('/docs')) {
      const docsUrl = new URL(request.url);
      docsUrl.hostname = 'docs-origin.example.com';
      return fetch(docsUrl, {
        headers: {
          ...request.headers,
          'X-Forwarded-Host': url.hostname,
        },
      });
    }
    
    // افتراضي: موقع التسويق الرئيسي
    return fetch(request);
  },
};

هذا يعمل على الحافة، يضيف كمون الحد الأدنى (عادة <5ms)، ويمنحك التحكم الكامل في التوجيه. يمكن لكل فريق النشر بشكل مستقل أثناء تقديم نطاق موحد لمحركات البحث.

المزالق لمراقبة

  • مسارات الأصول: تأكد من أن CSS و JS والصور الخاصة بمدونتك تستخدم مسارات نسبية أو يتم تقديمها من بادئة الدليل الفرعي الصحيحة.
  • الشرطات الزائدة: كن متسقاً. المزج بين /blog و /blog/ سيسبب حلقات إعادة التوجيه أو مشاكل المحتوى المكرر.
  • رؤوس الذاكرة المؤقتة: يحتاج الوكيل الحدودي إلى احترام وتمرير رؤوس الذاكرة المؤقتة بشكل صحيح.
  • شهادات HTTPS: طبقة الحافة الخاصة بك تحتاج إلى شهادة صالحة للنطاق الرئيسي. يمكن أن تستخدم الأصول الخلفية شهادات مختلفة.

الأخطاء الشائعة التي تدمر التصنيفات

الخطأ #1: نسيان 301 إعادات التوجيه أثناء الترحيل

هذا يبدو واضحاً، لكنني رأيت حدوثه أكثر من مرة أود أن أعترف به. كل عنوان URL قديم واحد يحتاج إلى 301 إعادة توجيه إلى موقعه الجديد. ليس 302. ليس meta refresh. إعادة توجيه 301 صحيحة.

الخطأ #2: مزج عمليات التشريع والموجه الفرعي

إذا كان كلا من blog.example.com/post و example.com/blog/post يحلان بشكل صحيح، فأنت بحاجة إلى علامات أساسية تشير إلى أحدهما أو الآخر. وجود كليهما بدون عمليات تشريع يعني أن Google تختار واحدة، وقد لا تكون الوحيد الذي تريده.

الخطأ #3: تجاهل ترحيل Google Search Console

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

الخطأ #4: نقل محتوى منخفض الجودة على النطاق الرئيسي الخاص بك

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

الخطأ #5: عدم تحديث الروابط الداخلية

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

إطار عمل القرار لعام 2026

إليك الإطار الذي أستخدمه عند تقديم المشورة للعملاء. لا يعقد، لكنه يعمل.

استخدم الدلائل الفرعية عندما:

  • المحتوى هو المقصود لتشغيل حركة المرور العضوية في البحث
  • المحتوى عالي الجودة ويعكس بشكل إيجابي على علامتك التجارية
  • يمكنك إدارة البنية الأساسية (حتى لو كان ذلك يعني وكيل عكسي)
  • SEO هو قناة نمو رئيسية لعملك

استخدم النطاقات الفرعية عندما:

  • التطبيق خلف المصادقة (لا قيمة SEO)
  • المحتوى ينتجه المستخدم وقد يكون منخفض الجودة
  • متطلبات الامتثال أو الأمان تتطلب العزل
  • المحتوى يستهدف جمهور/لغة مختلفة تماماً وكان لديك الموارد اللازمة لبناء السلطة لهذا النطاق الفرعي بشكل مستقل

النهج الهجين (الأكثر شيوعاً):

  • محتوى حاسم للـ SEO → الدلائل الفرعية (/blog و /docs و /resources)
  • التطبيقات → النطاقات الفرعية (app. و dashboard.)
  • التدريج/تطوير → النطاقات الفرعية (staging. و preview.)
  • الدعم/المجتمع → تقييم على أساس حالة تلو الأخرى

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

هل تريد مساعدة في معرفة البنية الأساسية الصحيحة لموقعك؟ نحن نعمل من خلال هذه الأنواع من القرارات بالضبط أثناء headless CMS و Next.js development الحلقات. يمكنك أيضاً التحقق من pricing أو التواصل مباشرة للدخول في حالتك المحددة.

الأسئلة الشائعة

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

هل يستحق ترحيل مدونتي من نطاق فرعي إلى دليل فرعي؟ في معظم الحالات، نعم -- خاصة إذا كان البحث العضوي قناة حركة مرور معنى لك. تُظهر البيانات بشكل متسق أن مدونات الدليل الفرعي تؤدي أداءً أفضل في البحث من مدونات النطاق الفرعي، كل شيء آخر متساوٍ. ومع ذلك، يحمل الترحيل نفسه مخاطر قصيرة الأجل (تقلبات في حركة المرور لمدة 2-4 أسابيع)، لذا قم بتخطيطها بعناية مع إعادة توجيهات 301 المناسبة وترحيل Search Console.

هل يمكنني استخدام إعادة كتابة Vercel بدلاً من وكيل عكسي؟ بالتأكيد. rewrites الخاص بـ Vercel في vercel.json أو next.config.js يعمل كوكيل عكسي على الحافة. هذا حل رائع إذا كان موقعك الرئيسي بالفعل على Vercel. يمكنك توكيل مسارات /blog إلى تطبيق منفصل تماماً مستضاف في مكان آخر، ومن منظور Google، يبدو أنه موقع واحد موحد.

كم من الوقت يستغرق Google للاعتراف بترحيل النطاق الفرعي إلى الدليل الفرعي؟ عادة 2-8 أسابيع لمعظم عناوين URL ليتم إعادة فهرستها في موقعها الجديد. تأخذ المواقع الأكبر بصفحات أكثر وقتاً أطول. استخدام أداة تغيير العنوان في Google Search Console وتقديم خريطة موقع محدثة يمكن أن يسرع هذا. توقع انخفاض ترتيب مؤقت في الأسابيع 1-2، متبوعاً بالتعافي وغالباً بتحسن.

هل تؤثر النطاقات الفرعية على نقاط Core Web Vitals؟ Core Web Vitals يتم قياسها لكل أصل (بروتوكول + اسم مضيف + منفذ). لذا blog.example.com لديها درجات CWV منفصلة تماماً عن example.com. هذا يمكن أن يكون ميزة إذا كانت مدونتك سريعة لكن موقعك الرئيسي بطيء، أو عكس ذلك. مع الدلائل الفرعية، صفحاتك الجيدة والسيئة تساهم جميعاً في تقييم CWV الأصل.

هل يمكنني استخدام النطاقات الفرعية والدلائل الفرعية لأغراض مختلفة؟ هذا هو بالفعل الأكثر شيوعاً والنمط الموصى به في 2026. ضع كل محتوى حاسم لـ SEO في الدلائل الفرعية (/blog و /docs و /resources). استخدم النطاقات الفرعية للتطبيقات وبيئات التدريج وأي محتوى تريد بوضوح عدم ربطه بإشارات جودة النطاق الرئيسي. المفتاح هو أن تكون مقصوداً حول المحتوى الذي يذهب إلى أين.

هل يؤثر الاختيار بين النطاق الفرعي والدليل الفرعي على سرعة الصفحة؟ ليس بطريقة متأصلة. تعتمد سرعة الصفحة على الاستضافة وتحسين الرمز وتسليم الأصول -- وليس على هيكل URL الخاص بك. ومع ذلك، فإن الدلائل الفرعية المخدومة من خلال وكيل عكسي تضيف كمية صغيرة من الكمون (عادة 1-10 ميلي ثانية) لقفزة الوكيل. هذا لا يذكر بشكل عملي. عامل سرعة الصفحة الأكبر هو ما إذا كنت تستخدم إطار عمل مناسب -- شيء مثل Astro للمواقع الغنية بالمحتوى سيتفوق على SPA ثقيل بغض النظر عن هيكل URL.

ماذا تقول البيانات عن أداء النطاق الفرعي مقابل الدليل الفرعي SEO في 2025-2026؟ تشير عمليات تحليل واسعة النطاق متعددة إلى نفس الاتجاه. أظهرت دراسة Ahrefs 2024 لـ 10000+ موقع أن صفحات الدليل الفرعي فاقت صفحات النطاق الفرعي المكافئة 60٪ من الوقت. أدى ترحيل HubSpot الخاص الموثق على نطاق واسع من مدونة نطاق فرعي إلى دليل فرعي إلى زيادة كبيرة في حركة المرور العضوية. بينما الارتباط ليس السببية، النمط متسق بما يكفي عبر الدراسات المختلفة وحالات الدراسة بحيث تكون الدلائل الفرعية هي الافتراضي الأكثر أماناً للمحتوى يركز على SEO.