نحن ننتقل من موقعنا على ووردبريس إلى منصة تجارة إلكترونية مستضافة على السحابة، والتي ستستخدم نطاقنا الأساسي نظرًا لترتيبنا العالي في تحسين محركات البحث.
أود نقل منشوراتنا إلى discourse، ولكن تشغيلها تحت نفس النطاق. هل هذا ممكن؟
وللتوضيح، فإن http://ultraluz.com.br/ سيعمل على خادم خارجي لا أستطيع التحكم فيه أو الوصول إليه، لذا أعتقد أنني لا أستطيع استخدام حيل nginx أو ما شابه. أملك فقط الوصول إلى الخادم الذي سيشغل discourse.
قد يكون من الممكن وضع Cloudflare أمام الموقعين مع قاعدة لتوجيه حركة المرور إلى Discourse للمجلد الفرعي. أنا لست على علم بأن أي شخص فعل ذلك. ربما ستحتاج إلى توظيف شخص ما أو حل الأمر بنفسك. فقط اتبع الموضوع هنا حول تثبيتات المجلدات الفرعية وما لديه Cloudflare حول نفس الأمر.
كنت أعتقد أن الاعتقاد بأن المجلد الفرعي أفضل لتحسين محركات البحث قد تلاشى. توصيتي هي ببساطة استخدام نطاق فرعي، ولكن إذا كان لديك ميزانية، فاتصل بي أو انشر في Marketplace.
يمكنك نظريًا تحقيق جزء المجلد الفرعي في Cloudflare باستخدام قاعدة صفحة Enterprise أو ربما عبر Workers، لكنني أشك بشدة في قدرتنا على تقديم أي مساعدة في أي من الحالتين.
من الصعب دعم Cloudflare بأي شكل يتجاوز DNS.
ونعم، دحضت جوجل نفسها تمامًا ادعاءات تحسين محركات البحث (SEO) غير الموثوقة حول حشر كل شيء تحت نطاق واحد.
الأمان أفضل من الندم في تحسين محركات البحث (SEO). لا أرى كيف يمكن أن يعزز نطاق فرعي مثل blog.domain تحسين محركات البحث لنطاقك الرئيسي، لذا لا فائدة من استخدام نطاق فرعي للمدونة على الإطلاق.
لقد كنت أفكر في اتباع هذا الدليل. أي من الخيارات التالية يجب أن أستخدمه؟
كان بإمكاني إضافة المزيد من الروابط المدعومة بالبيانات لو لم أكن مقيدًا ب رابطين فقط. وباستثناء Cloudflare، وهي شركة ضخمة ولا تحتاج إلى التركيز على تحسين محركات البحث، فإن جميع المواقع في الصفحة الأولى لنتائج هذا البحث تستخدم المجلدات الفرعية.
لن يكون من الصعب العثور على أماكن أخرى يعتقد فيها الناس نفس الشيء، حيث يبدو أن هذا هو الإجماع في مجتمع تحسين محركات البحث.
لكن بالتأكيد، إذا كانت لديك أي دليل على أن النطاقات الفرعية تساعد في تحسين ترتيب النطاق الجذري، فيرجى إضاءة الإنترنت بذلك
صحيح! من الأفضل بكثير فعل شيء يتفق معظم الناس على أنه لن يساعد في ترتيب المواقع، لكنه قد يؤدي على الأرجح إلى توقف موقعك بشكل غير متوقع دون وجود وسيلة واضحة لإصلاحه.
كمعيار مرجعي، سأفرض عليك رسومًا تقدر بحوالي 1000 دولار ولن أضمن أن يعمل الأمر لأكثر من أسبوع بعد إعداده. (أو ربما أفرض عليك 500 دولار دون ضمان قدرتي على حل المشكلة من الأساس.
وستحتاج إلى خطة Cloudflare Enterprise.
إذا كنت مهتمًا، انشر في قناة Marketplace واذكر الميزانية المتاحة، وأيضًا أنك مستعد لدفع تكاليف خطة Cloudflare Enterprise، مع إدراك أن الأمر على الأرجح مستحيل.
فكرتي هي أنه بعد إصلاح هذا، سأستخدم ملف robots.txt لمنع Google من فهرسة نطاقك الفرعي، بحيث يرى ويفهرس فقط /blog، بينما لا يزال بإمكانني الوصول إلى النطاق الفرعي بسهولة إذا لزم الأمر.
لن يعمل هذا أبدًا بشكل جيد مع “تثبيت عادي”، يجب عليك حقًا اتباع إجراءات التثبيت في مجلد فرعي. سيحل هذا مشكلات CSP والعديد من المشكلات الأخرى. وبالإضافة إلى ذلك، أعتقد أنك تقترب من الانتهاء.
لم ينجح الأمر بهذه الطريقة. أعتقد أن السبب هو أن العامل (worker) يحتاج إلى نطاق لجلب البيانات، وبما أن النطاق الجذر موجود على عنوان IP مختلف.
أنا في الأساس أخبر العامل: “عندما يزور شخص ما /blog، قم بجلب هذا من rootdomain/blog”، وهذا بالطبع يعرض فقط صفحة خطأ 404 الخاصة بـ WordPress الحالية.
أعتقد أنه بسبب مسألة النطاق الواحد مع عناوين IP/خوادم متعددة، فإن استخدام نطاق فرعي ضروري لتحميل أصول Discourse. لكن الوقت متأخر الآن ويحتاج الأمر إلى النوم.
لكنني أعتقد أن أسهل طريقة لتحقيق ذلك هي ببساطة إصلاح أخطاء سياسة محتوى الأمان (CSP) باستخدام تثبيت النطاق الفرعي المعتاد.