क्या मेरे URL को कम किया जाना चाहिए?

17

इस ब्लॉग के अनुसार ("अंडरस्टैंडिंग एसईओ फ्रेंडली यूआरएल सिंटैक्स प्रैक्टिसेस") मुझे बदलना चाहिए

http://example.com/Hello-Dolly

सेवा

http://example.com/hello-dolly

दिए गए कारण हैं:

URL, सामान्य रूप से, केस-संवेदी होते हैं

यह किसी भी मामले संवेदनशील एसईओ और विश्लेषिकी रिपोर्ट को सरल करेगा

इस जीआईएफ के अनुसार जो मैंने URL नॉर्मलाइज़ेशन पर विकिपीडिया के लेख पर पाया है मुझे अपने URL को किसी भी अपरकेस से सभी लोअरकेस में बदलना चाहिए।

हालाँकि मैं ASP.NET MVC का उपयोग करता हूँ और डिफ़ॉल्ट रूप से मेरे URL इस तरह से संरचित हैं ( CamelCase ):

http://www.example.com/Controller/Action/Parameter

http://www.example.com/Categories/List/Bicycles

मैंने RFC1738 के माध्यम से स्किम्ड किया है, लेकिन मुझे इसका कोई निश्चित उत्तर नहीं मिला।

क्या मुझे अपने रास्ते से बाहर जाना चाहिए ताकि फ्रेमवर्क को कम मामले में सब कुछ बदलने के लिए मजबूर किया जा सके? Microsoft ने अपने ढांचे को इस तरह डिजाइन करने का विकल्प क्यों चुना अगर हर कोई मुझे लोअरकेस का उपयोग करने के लिए कह रहा है?

url asp.net-mvc

— रोवन फ्रीमैन
स्रोत

3

Webmasters.stackexchange.com पर समुदाय के लिए आपकी क्वेरी के शानदार प्रश्न और अद्भुत प्रस्तुति! आपने वास्तव में पूछने से पहले इस मुद्दे पर अपना 'होमवर्क' किया था!

— dvnkiss

मैं एक समस्या में भाग गया, जहां एक प्रॉक्सी ने अनुरोधित URL को सभी लोअरकेस में बदल दिया - और एक लिनक्स सर्वर के अनुरोध पर 404 का कारण बना, जिसने मेरे //SO/ उपनिर्देशिका (जहां मैंने स्टैकओवरफ़्लो उदाहरण डाला) में एक पृष्ठ की मेजबानी की। यह एक ऐसा मामला है जहां लोअरकेस में फर्क पड़ता है (आप तर्क कर सकते हैं कि प्रॉक्सी बुरी तरह से कोडित थी लेकिन यह वास्तविक जीवन है ...)

— फ्लोरिस

10

Should I go out of my way to force the framework to change everything to lower case?

नहीं, यह आवश्यक नहीं है। विंडोज ऑपरेटिंग सिस्टम केस असंवेदनशील हैं, जिसमें उनके सर्वर OS और फ्रेमवर्क एप्लिकेशन शामिल हैं। हालांकि लिनक्स / यूनिक्स ऑपरेटिंग सिस्टम संवेदनशील हैं।

इंटरनेट-आधारित एप्लिकेशन (जैसे, ब्राउज़र) को URL की सामान्यीकृत करना चाहिए , जैसा कि RFC 3986 की धारा 6 में शामिल है :

यूआरआई पर सबसे आम संचालन में से एक सरल तुलना है: यह निर्धारित करना कि क्या दो यूआरआई अपने संबंधित संसाधन (ओं) तक पहुंचने के लिए यूआरआई का उपयोग किए बिना बराबर हैं। प्रतिसाद कैश पहुंचने पर हर बार एक तुलना की जाती है, एक ब्राउज़र एक लिंक को रंगने के लिए अपने इतिहास की जांच करता है, या एक नाम के भीतर XML पार्सर टैग टैग करता है। यूआरआई की तुलना से पहले व्यापक सामान्यीकरण अक्सर मकड़ियों और अनुक्रमण इंजनों द्वारा एक खोज स्थान को कम करने या अनुरोध कार्यों और प्रतिक्रिया भंडारण के दोहराव को कम करने के लिए उपयोग किया जाता है।

चूंकि आप एक विंडोज सर्वर का उपयोग कर रहे हैं, इसलिए इसमें कोई संदेह नहीं है, अनुरोधित यूआरएल और यूआरआई क्लाइंट अनुप्रयोगों को ठीक कर दिए जाएंगे।

खोज इंजन के संबंध में, जैसा कि ऊपर RFC में कहा गया है, और URL सामान्यीकरण पर आपके विकिपीडिया लिंक में :

वेब पृष्ठों को महत्व देने और डुप्लिकेट पृष्ठों की अनुक्रमणिका को कम करने के लिए खोज इंजन URL सामान्यीकरण को नियोजित करते हैं।

और इस विषय पर इस रिपोर्ट के स्रोत के रूप में :

हाल ही में, Google ने बेहतर तरीके से समझना शुरू किया कि /page1.html और /पेज 1.html एक ही सामग्री के केवल दो उदाहरण हैं।

Why did Microsoft choose to design their framework like this if everybody is telling me to use lowercase?

यह उनके ऑपरेटिंग सिस्टम के साथ संगत है, और RFC के अनुसार तकनीकी रूप से गलत नहीं है। उनके पास चीजों को करने का अपना तरीका भी है, जो वेबमास्टर्स का अनुमान लगाता है :-)

— दान
स्रोत

1

महान जवाब, मैं बहुत ही समान उत्तर पोस्ट करने जा रहा था, लेकिन आपने मुझे इसे हरा दिया! "माइक्रोसॉफ्ट ने इस तरह से अपने ढांचे को डिजाइन करने का विकल्प क्यों चुना अगर हर कोई मुझे लोअरकेस का उपयोग करने के लिए कह रहा है? ... उनके पास चीजों को करने का अपना तरीका भी है, जो वेबमास्टर्स को अनुमान लगाता रहता है।" - उस बिट से प्यार करो। जहाँ तक मुझे याद है कि माइक्रोसॉफ्ट के पास डेवलपर्स / वेबमास्टरों को उनके कठोर नियमों के लिए झुकने के लिए अपने स्वयं के साधन हैं!

— dvnkiss

4

मुझे नहीं पता है कि आपको इसे बदलना चाहिए लेकिन आपको लगातार सुनिश्चित करना चाहिए।

मैंने कुछ साल पहले इस पर ध्यान दिया था और Google का मानक था कि TLD से कोई फर्क नहीं पड़ता, लेकिन TLD के बाद।

उस समय मैं एक डिफंक्ट साइट पर काम कर रहा था जिसे बुलाया गया था BusinessForPhotographers.com; जाहिर है कि मामले को असंवेदनशील माना जाता है।

के बाद .comएक और मामला है। यदि आप सर्वर को उसी स्थान पर रूट करते हैं, तो भी Google विचारों /Great-Articleसे अलग /great-articleहै।

यह विहितकरण और डुप्लिकेट सामग्री मुद्दों को प्रभावित कर सकता है। मुझे लगता है कि सबसे सुरक्षित तरीका 301 संस्करण को सही संस्करण के लिए मजबूर करना होगा।

हालांकि यह YouTube जैसी सेवा के बारे में व्यर्थ लग सकता है, क्या /A1B2C3यह उतना ही URL है /a1b2c3?

गूगल की नजर में नहीं।

— एडम-asdf
स्रोत

3

URI पथ केस-संवेदी होते हैं (यदि अन्यथा परिभाषित नहीं हैं)। देखें यूआरआई मानक STD 66, खंड 6.2.2.1। मामला सामान्यीकरण :

अन्य सामान्य वाक्यविन्यास घटकों को केस-संवेदी माना जाता है जब तक कि योजना द्वारा विशेष रूप से परिभाषित नहीं किया गया हो

यदि HTTP URI पथों में अपरकेस अक्षर कुछ उपयोगकर्ताओं के लिए एक समस्या होगी, तो विकिपीडिया उनके लिए टूट जाएगा। ये दो HTTP यूआरआई (केवल लोअरकेस oबनाम अपरकेस में भिन्न होते हैं O) अलग-अलग पृष्ठों तक ले जाते हैं:

तो नहीं, आपको अपने यूआरआई को बदलने की जरूरत नहीं है ।

हालांकि, यदि संभव हो (यदि आप मामले का उपयोग नहीं करते हैं, जैसा कि विकिपीडिया करता है), तो सभी मामलों के वेरिएंट और 301 को एक विहित संस्करण में पुनर्निर्देशित करने की अनुमति देना अच्छा होगा ।

— UNOR
स्रोत