نطاق فرعي أم مجلد فرعي؟ تخطيط الموقع
· PoolByte Technology
يحدد اختيار النطاق الفرعي والمجلد الفرعي المكان الذي سيتم فيه تشغيل مدونة أو متجر أو منطقة عملاء جديدة داخل الموقع. يعد blog.example.com مثالاً للمجال الفرعي وexample.com/blog مثالاً للمسار ضمن نفس المضيف. بدلاً من اتخاذ القرار بناءً فقط على قصر العنوان أو مطالبة تحسين محركات البحث (SEO) المسموعة، من الضروري تقييم التطبيق والفريق ورحلة المستخدم معًا.
أولا تحديد وظيفة القسم
المدونة هي في الغالب قسم المحتوى في موقع التسويق. يمكن لبوابة العملاء إجراء عمليات مختلفة مثل تسجيل الدخول والفاتورة وإدارة الخدمة. إذا كانت هناك حاجة إلى برامج أخرى، أو عملية نشر منفصلة، أو قواعد وصول مختلفة، فقد يكون النطاق الفرعي منطقيًا من الناحية التشغيلية. بالنسبة للقسم الذي يعمل على نفس نظام إدارة المحتوى، يمكن للمجلد الفرعي إنشاء تخطيط أبسط.
لا يتفوق أي من هذين الخيارين في كل مشروع. يجب أن يتضمن جدول القرار الخاص بك البرنامج المستخدم، والفريق المسؤول، وتكرار التحديث، ومتطلبات الجلسة، وما إذا كان هناك محتوى مفتوح لمحركات البحث. إن تسجيل الأساس المنطقي الحقيقي يمنع تغيير البنية لاحقًا لمجرد أنها عصرية.
قارن بين مسؤولية النشر والصيانة
يمكن ربط النطاق الفرعي بتطبيق منفصل؛ لهذا، يتم إعداد DNS وHTTPS وعناوين التطبيق معًا. إذا كان موجودًا في مجلد فرعي، فقد يحتاج الخادم إلى إعادة توجيه هذا المسار إلى التطبيق الصحيح. إن تشغيل تطبيق ثانٍ ضمن نفس الموقع لا يقتصر فقط على فتح مجلد. يجب التحقق من مسارات الملفات الثابتة وإعدادات عنوان URL الأساسية للتطبيق.
في مثال الأعمال، قد يقوم فريق المحتوى بإدارة موقع التسويق وقد يقوم فريق البرامج بإدارة تطبيق العميل. يمكن أن يدعم جدول النشر المنفصل وتتبع الأخطاء قرار النطاق الفرعي. إذا كان نفس الفريق يدير نظام إدارة محتوى واحدًا، فقد يؤدي فصل المدونة بشكل منفصل إلى إنشاء عبء صيانة غير ضروري. اختر تخطيطًا متوافقًا مع موارد العمل؛ لا يقوم العنوان المنفصل تلقائيًا بإنشاء خادم منفصل أو حدود أمان.
تخطيط سلوك الجلسة من الصفر
قد يكون للنطاقات الفرعية أصول مختلفة اعتمادًا على المتصفح. إن الارتباط بنفس المجال الجذر لا يمنح وصولاً مشتركًا غير مقيد إلى بيانات التطبيق. يتم أيضًا تكوين نطاق ملف تعريف الارتباط بشكل منفصل. تشرح نفس سياسة الأصل ودليل ملفات تعريف الارتباط HTTP لـ MDN الأساس الفني لهذه الفروق.
إذا قام العميل بتسجيل الدخول إلى الموقع الرئيسي ومن المتوقع أن يقوم بتسجيل الدخول إلى البوابة، فيجب تصميم هذا السلوك بشكل آمن بواسطة التطبيق. يتم اختبار تسجيل الدخول وتسجيل الخروج وجلسة منتهية الصلاحية واتصالات العودة بشكل منفصل. بدلاً من اختيار تغطية واسعة لملفات تعريف الارتباط من أجل الراحة فقط، فكر في علاقات الثقة للنطاقات الفرعية الأخرى. يجب أن يكون واضحًا أن إدارة الجلسة للتطبيقات الفردية تقع على عاتق المطور.
اتخذ قرارات تحسين محركات البحث فيما يتعلق بالمحتوى والإدارة
لن يؤدي فتح نطاق فرعي وحده إلى زيادة تصنيفاتك. لا يقوم المجلد الفرعي أيضًا بإصلاح المحتوى المفقود أو الروابط المعطلة تلقائيًا. يجب إنشاء الروابط ومعلومات البيانات الوصفية ونطاق المحتوى والوصول إلى خريطة الموقع إلى القسم الذي يمكن لمحرك البحث الوصول إليه بشكل صحيح. صفحات العملاء التي تتطلب تسجيل الدخول وأوصاف الخدمة العامة لها أغراض مختلفة.
في المشاريع متعددة اللغات، يمكن أيضًا مراعاة النطاقات الفرعية أو المجلدات الفرعية أو أنظمة أسماء النطاقات المختلفة. يغطي مستند المواقع المتعددة الخاص بـ Google الجانب الإداري لهذه الخيارات. فصل كل قسم لا يعني تحسين محركات البحث بشكل أفضل؛ مطلوب محتوى مدعوم حقًا وعلاقات لغوية متسقة.
اجعل انتقال المستخدم واضحًا
يجب أن تكون العلامة التجارية والغرض من الصفحة وسلوك القائمة واضحين عند الانتقال من الموقع الرئيسي إلى منطقة العميل. يجب ألا يرى المستخدم فجأة قوائم غير ذات صلة أو أسماء خدمات مختلفة. اختبر وجهة الروابط مثل "العودة إلى الموقع" و"خدماتي" و"الدعم" بمهام حقيقية. يجب أن يتم تحديد مسبقًا ما إذا كان سيتم الاحتفاظ بالسلة أو اختيار اللغة بين التطبيقات.
حاول أيضًا الانتقال على شاشة الهاتف. هل يتغير عرض الصفحة عند فتح القائمة، هل زر الرجوع يأخذك إلى المكان الصحيح، هل تفتح الصفحة المتوقعة بعد تسجيل الدخول؟ إن مجرد عمل ثلاثة تطبيقات بشكل منفصل لا يعني أنها معًا تخلق تجربة جيدة للعملاء. يجب إكمال سيناريو الترحيل من البداية إلى النهاية.
أسئلة قصيرة لاتخاذ القرار
- هل سيعمل القسم على نفس البرنامج وتخطيط المحتوى؟
- هل يلزم وجود فريق منفصل أو جدول نشر منفصل؟
- هل من المتوقع عقد جلسات وسلال مشتركة؟
- ما هي صفحات القسم التي ستكون مفتوحة لمحرك البحث؟
- من سيكون مسؤولاً عن DNS وHTTPS والمراقبة؟
- كيف سيتم الحفاظ على الاتصالات القديمة إذا تغير العنوان في المستقبل؟
عند تغيير بنية العنوان، يمكنك استخراج خطة الترحيل من دليل التوجيه 301 . راجع دليل الموقع متعدد اللغات للتعرف على تخطيط اللغة، وصفحة الاتصال بـPoolByte لتقييم نطاق التنفيذ والاستضافة لمشروعك. إن البنية المثالية هي التي تدعم بوضوح طريقة عملك الحالية والمستقبلية.