الهيكل القانوني لـ /u/* يتسبب في فهرسة العديد من عناوين URL

[stance455 (Nader)]

في البداية، كتبت هذا لفئة “خطأ”…

… ولكن لا تدعني أوقفك إذا شعر أي شخص أن هذا يستحق طلب سحب أو تثبيت

لقد درست بنية Discourse الأساسية بجد خلال الشهرين الماضيين وبشكل عام إنها رائعة.

عناوين URL الغريبة مع أشياء مثل no_definitions=true أو /search?q= تعطي العنوان الأساسي الصحيح.

كل هذا يعمل عند تقديم إصدار JavaScript للموقع للمستخدمين والزواحف على حد سواء.

ولكن يبدو أن عناوين URL /u/* قد تم تجاهلها - فهي تحتوي على عناوين أساسية، ولكن لعناوين URL التي تتسبب في فهرسة آلاف العناوين الإضافية بواسطة Google.

المهمة:

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

لذا /u/FlyNumber هي صفحة الملف الشخصي الرئيسية.

سيحتوي ما يلي على عنوان أساسي للصفحة المذكورة أعلاه (بدلاً مما يحدث الآن، وهو عنوان أساسي لنفسه):

/u/FlyNumber/summary
/u/FlyNumber/activity
/u/FlyNumber/activity/topics
/u/FlyNumber/activity/replies
/u/FlyNumber/activity/likes-given
/u/FlyNumber/badges

[justin (Justin DiRose)]

هل هذا لإعداد الفهرسة المخصص الخاص بك الذي تمت مناقشته هنا؟

Need "window.prerenderReady" implemented on my instance [PAID GIG]

I’m using prerender.io to serve the “application/JS” version of the site to crawlers ( my instance serves crawlers the JS version via a hidden setting ) It’s working well but seems discourse might fall under this category … but some web pages use some custom loading flows or constant polling that may trick Prerender’s logic; thus, it fails to make a decision on the ready-ness of the page. The first time prerender accesses any discourse URL, it will timeout ( 20 seconds set by prerender ) T…

إذا كان الأمر كذلك، فقد يكون من المفيد ملاحظة ذلك حتى يعرف أولئك الذين ينظرون إلى الوظيفة ما الذي يواجهونه.

بشكل افتراضي، لا تتم فهرسة عناوين URL /u/، والتي يتم تعيينها في robots.txt ويتم تمريرها في طلب الرأس الأولي للصفحة.

[stance455 (Nader)]

@justin

هل هذا لإعداد الفهرسة المخصص الخاص بك الذي تمت مناقشته هنا؟

لا، لقد توقفت عن استخدام prerender - لم يتمكن من عرض القائمة الرئيسية، وزر تسجيل الدخول، وما إلى ذلك.
يتم إعطاء روبوت جوجل “التطبيق” مباشرة.
لدي إعداد موقع discourse مخفي لتقديم النسخة التي تعمل بالـ JavaScript لمحركات الزحف. يبدو أن جوجل تتعامل معها بشكل جيد. (المزيد من التحديثات حول ذلك قريباً.)

@justin

بشكل افتراضي، لا تتم فهرسة عناوين URL التي تبدأ بـ /u/

نقطة جيدة، /badges أيضاً…

@justin

قم بتعيين كليهما في robots.txt

أنا أستخدم ملف robots معدل خصيصًا.

@justin

وتم تمريرها في طلب الرأس الأولي على الصفحة.

أنا أستخدم Cloudflare workers لـ تغيير الرأس إلى 'index'.

[stance455 (Nader)]

@justin

بشكل افتراضي، لا تتم فهرسة عناوين URL /u/، وهو ما يتم تعيينه في robots.txt ويتم تمريره في طلب الرأس الأولي على الصفحة.

/u/FlyNumber/summary
/u/FlyNumber/activity
/u/FlyNumber/activity/topics
/u/FlyNumber/activity/replies
/u/FlyNumber/activity/likes-given
/u/FlyNumber/badges

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

كما هو مذكور أعلاه، تم تعيينها على noindex لذلك لست متأكدًا من سبب قيام Discourse بإنشاء الرابط الكنسي على الإطلاق.

[stance455 (Nader)]

ربما يعرف شخص ما طريقة ذكية للقيام بذلك باستخدام JS وعمال Cloudflare؟ بهذه الطريقة أتجنب العبث بكود Discourse.

يمكنني إعداد “مشغل” على <s/>/u/*/summary<s/> - (يمكنني فقط التشغيل على /u/*) - وتنفيذ شيء مثل هذا:

const canonical = document.querySelector('link[rel="canonical"]');
if (canonical !== null) {
  canonical.href = 'NEW_HREF_GOES_HERE';
}

ماذا يمكنني أن أفعل هنا لتمرير اسم المستخدم إلى NEW_HREF_GOES_HERE - وسينتهي الأمر بأن يكون الرابط الأساسي هو /u/* بدلاً من /u/*/summary.

أي مساعدة هنا موضع تقدير كبير.

تعديل
ربما يمكن لشخص ما الإشارة إلى صفحة (صفحات) GitHub ذات الصلة - سأخاطر بتعديل الكود.