मुझे अपने URL में ट्रेलिंग स्लैश का उपयोग कब करना चाहिए?

282

URL में ट्रेलिंग स्लैश का उपयोग कब किया जाना चाहिए? उदाहरण के लिए - क्या मेरा यूआरएल लाइक /about-us/या लाइक होना चाहिए /about-us?

मैं एसईओ से संबंधित मुद्दों से पूरी तरह अवगत हूं - डुप्लिकेट सामग्री और विहित चीज़; मैं यह पता लगाने की कोशिश कर रहा हूं कि मुझे पृष्ठों को सही ढंग से परोसने के संदर्भ में किसका उपयोग करना चाहिए ।

उदाहरण के लिए, मेरा सहकर्मी सोच रहा है कि अंत में पीछे चल रहा स्लैश का अर्थ है "फ़ोल्डर" - एक "निर्देशिका", इसलिए यह एक सही शैली नहीं है। लेकिन मुझे लगता है कि अंत में बिना किसी स्लैश के - यह बिल्कुल भी सही नहीं है, क्योंकि यह लगभग एक फ़ोल्डर की तरह दिखता है, लेकिन यह नहीं है और यह सामान्य फ़ाइल भी नहीं है, लेकिन विस्तार के बिना फ़ाइल नाम।

क्या यह जानने का एक उचित तरीका है कि किसका उपयोग करना है?

— डेनिस
स्रोत

ट्रेलिंग स्लैश, लेकिन मेरी राय में यह मुख्य रूप से सौंदर्यशास्त्र है। देखो और महसूस।

— एरिक हेर्लिट्ज़

3

प्रो वेबमास्टर्स पर एक ही सवाल: क्या यह एक फर्क पड़ता है कि क्या आपका URL पथ अनुगामी स्लैश में समाप्त होता है या नहीं?

— स्टीफन ओस्टरमिलर

4

इस प्रश्न को वरीयता में से एक के रूप में प्रस्तुत किया गया है , और इस तरह यह मुख्य रूप से राय-आधारित विषय के रूप में प्रतीत होगा । हालांकि, जैसा कि मेरा उत्तर दिखाता है, वास्तव में इस प्रश्न को वरीयता के रूप में प्रस्तुत करना एक गलती है: यह एक XY समस्या है, और अंतर्निहित "वास्तविक" प्रश्न का सटीक तकनीकी उत्तर है, और इस प्रकार मुख्य रूप से राय आधारित नहीं है ।

— राेडवल्ड 12

Google को किस प्रकार के URL पसंद हैं, इस बारे में प्रश्न प्रोग्रामिंग से संबंधित नहीं हैं (जैसा कि टैग विकी में वर्णित है ) और Stackoverflow के लिए ऑफ-टॉपिक हैं।

— क्वेंटिन

मैंने आपके प्रश्न के लिए कुछ संपादन किए हैं, कृपया उन्हें दोबारा जांचें जब आपके पास ऐसा करने का अवसर हो। धन्यवाद :)

— टिम पोस्ट

131

मेरी व्यक्तिगत राय में, स्लैशिंग का दुरुपयोग किया जाता है।

मूल रूप से URL प्रारूप फ़ाइलों और फ़ोल्डरों के समान UNIX प्रारूप से आया था, बाद में, डॉस सिस्टम पर, और अंत में, वेब के लिए अनुकूलित किया गया।

यूनिक्स-जैसे ऑपरेटिंग सिस्टम पर इस पुस्तक के लिए एक विशिष्ट URL एक फ़ाइल पथ होगा जैसे फ़ाइल: ///home/username/RomeoAndJuliet.pdf, स्थानीय फ़ाइल डिस्क पर फ़ाइल में सहेजी गई इलेक्ट्रॉनिक पुस्तक की पहचान करना।

स्रोत: विकिपीडिया: यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर

पढ़ने के लिए एक और अच्छा स्रोत: विकिपीडिया: यूआरआई योजना

1994 में URL परिभाषित करने वाले RFC 1738 के अनुसार, जब संसाधनों में अन्य संसाधनों के संदर्भ होते हैं, तो वे दूसरे लिंक के स्थान को परिभाषित करने के लिए रिश्तेदार लिंक का उपयोग कर सकते हैं जैसे कि यह कहना है, "निम्न स्थान के अलावा इस एक के रूप में एक ही स्थान पर" पथ "। यह ऐसा है कि सापेक्ष URL, एक सौपानिक संरचना जिसके खिलाफ रिश्तेदार लिंक आधारित है जिसमें मूल URL पर निर्भर हैं, और कहा कि एफ़टीपी, http, और फ़ाइल URL योजनाओं कुछ है कि श्रेणीबद्ध माना जा सकता है के उदाहरण हैं कहने के लिए पर चला गया के साथ पदानुक्रम के घटकों को "/" द्वारा अलग किया जा रहा है।

स्रोत: विकिपीडिया यूनिफ़ॉर्म रिसोर्स लोकेटर (URL)

इसके अलावा:

यह वह सवाल है जो हम अक्सर सुनते हैं। जवाब के लिए आगे! ऐतिहासिक रूप से, यह एक निर्देशिका को इंगित करने के लिए अनुगामी स्लैश वाले URL के लिए सामान्य है, और एक अनुगामी स्लैश के बिना किसी कॉल को अस्वीकार करने के लिए:

http://example.com/foo/ (अनुगामी स्लैश के साथ, पारंपरिक रूप से एक निर्देशिका)

http://example.com/foo (स्लैश को पीछे किए बिना, पारंपरिक रूप से एक फ़ाइल)

स्रोत: गूगल वेबमास्टर सेंट्रल ब्लॉग - स्लैश या स्लैश करने के लिए नहीं

आखिरकार:

URL के अंत में एक स्लैश पता को "सुंदर" बनाता है।
अंत में बिना स्लैश वाला और बिना एक्सटेंशन वाला URL कुछ हद तक "अजीब" लगता है।
आप कभी भी अपनी CSS फ़ाइल का नाम नहीं लेंगे (उदाहरण के लिए) http://www.sample.com/stylesheet/ क्या आप?

लेकिन, मैं पर्यावरण की परवाह किए बिना वेब सर्वोत्तम प्रथाओं का प्रस्तावक बन रहा हूं। यह जीता और अस्पष्ट हो सकता है, जैसा कि आपने URL के बारे में कहा था जिसमें कोई ext नहीं है।

— Dementic
स्रोत

1

यह अजीब है, आप एक फ़ाइल "स्टाइलशीट /" का नाम नहीं दे सकते हैं - और स्लैश या कोई स्लैश सर्वर पर पूरी तरह से अलग संसाधन हैं, कोई फर्क नहीं पड़ता कि URL कैसा दिखता है

— nico gawenda

10

@nicogawenda, .htaccess सभी प्रकार के जादू कर सकता है;) आपका CSS वास्तव में एक php फाइल हो सकता है!

— 15

4

index.htmlजब कोई निर्देशिका एक्सेस की जाती है, तो वेब सर्वर को अक्सर डिफ़ॉल्ट रूप से सेवा (या इसी तरह नामित फ़ाइल) के लिए सेट किया जाता है, इसलिए /foo/यह /foo/index.htmlअतिरिक्त गड़बड़ नहीं है। इसके अलावा, अतीत में, ब्राउज़र /डोमेन नाम के लिए संलग्न होंगे , लेकिन वे (फ़ायरफ़ॉक्स, क्रोम, ओपेरा) तब से बदल गए हैं /जब होमपेज पर पहुंच को छोड़ दिया जाता है ।

— 0b10011

4

मैं @bfrohs से सहमत हूं। निश्चित रूप से निर्देशिकाओं के लिए डिफ़ॉल्ट पृष्ठ इस सिद्धांत का उल्लंघन करते हैं। अगर हम 'ट्रेलिंग स्लैश = निर्देशिका' को लागू करते हैं, तो निश्चित रूप से एक निर्देशिका में इंगित करने वाले सभी यूआरएल या तो निर्देशिका लिस्टिंग या 403 निषिद्ध http प्रतिक्रिया को वापस करना होगा।

— मार्विन

11

मुझे यकीन नहीं है कि "अंत में" अनुभाग में अंक # 1 और 2 अभी भी सटीक हैं। वर्षों से यह मूल रूप से लिखा गया था, स्वाद बदल गया है। मैंने इस पर विस्तार से अध्ययन नहीं किया है, लेकिन ऐसा लगता है कि नई वेबसाइटों पर, स्लैश को छोड़ना अधिक सामान्य और "प्रेटियर" है।

— स्पीडप्लेन

171

यह वरीयता का सवाल नहीं है। /baseऔर /base/अलग-अलग शब्दार्थ हैं। कई मामलों में, अंतर महत्वहीन है। लेकिन यह महत्वपूर्ण है जब रिश्तेदार URL होते हैं।

childके सापेक्ष /base/है /base/child।
childके सापेक्ष /baseहै (शायद आश्चर्यजनक रूप से) /child।

— Raedwald
स्रोत

5

सहायक लेख जो इस पर कुछ गहराई में जाता है: cdivilly.wordpress.com/2014/03/11/…

— Hephaestus

3

हां, मुझे लगता है कि एसईओ के साथ-साथ, इस प्रश्न के लिए सबसे महत्वपूर्ण चीजें हैं।

— user2875289

.Net का उपयोग करते समय बस इस समस्या से गुजरा Uri.MakeRelativeUri। परिणाम वास्तव में आप क्या कहा प्रतिबिंबित करते हैं। मैंने अपने आधार में ट्रेलिंग स्लैश को जोड़कर समस्या को ठीक किया Uri।

— जुलैलेगन

61

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

स्लैश हमेशा निर्देशिकाओं को निरूपित करते हैं, कभी फाइलें नहीं।
फ़ाइलों को कुछ भी नाम दिया जा सकता है (एक्सटेंशन के साथ या बिना), लेकिन स्लैश के साथ शामिल या समाप्त नहीं हो सकता है।

इन दिशानिर्देशों का उपयोग करते हुए, गैर-निर्देशिका संसाधन के बाद स्लैश डालना गलत है।

— Yarin
स्रोत

50

"निर्देशिकाओं के बाद स्लैश, संसाधनों के बाद नहीं": URL दो प्रकार की चीज़ों का उल्लेख नहीं करते हैं, "संसाधन" और "निर्देशिका"; वे एक तरह की चीज का उल्लेख करते हैं: संसाधन। सुराग R के URL में है।

— रायडवल

31

और * nix फाइल सिस्टम में सब कुछ एक फाइल है, लेकिन डायरेक्टरी अभी भी मौजूद है। अापका नजरिया क्या है?

— यारिन

6

चाहे यह एक फ़ाइल या एक निर्देशिका द्वारा आंतरिक रूप से सेवा की जाती है, जो उपयोगकर्ता देखता है वह सिर्फ एक वेब पेज है। और example.com/about वास्तव में example.com/about/index.html से पढ़ा जा सकता है ।

— मुशफिल

1

@DavidRR: आप सही कह रहे हैं। और ब्राउज़र को पुनर्निर्देशित करने की आवश्यकता है क्योंकि नाम रिज़ॉल्यूशन अंदर से directory(अन्यथा, image.pngमें) होना हैhttp://hostname/directory को इंगित करेंगे http://hostname/image.png)। मैं सिर्फ यह कह रहा था कि फ़ाइल और निर्देशिका के बीच का अंतर उपयोगकर्ता के दृष्टिकोण से बहुत महत्वपूर्ण नहीं हो सकता है।

— मुशिफिल

2

मैं आपके परिणाम से सहमत हूं, लेकिन मुझे यकीन नहीं है कि हमें * nix-style फ़ाइल सिस्टम का अनुकरण करने के लिए अपना URL सिस्टम डिज़ाइन करना चाहिए। यह मूल रूप से एक उद्देश्य परोस सकता है, लेकिन अब बहुत कम है।

— स्पीडप्लेन

27

यह वास्तव में सौंदर्यशास्त्र का सवाल नहीं है, लेकिन वास्तव में एक तकनीकी अंतर है। इसके बारे में सोच की निर्देशिका पूरी तरह से सही है और बहुत कुछ समझा रही है। चलो इसे बाहर काम करते हैं:

अब आप पाषाण युग में वापस आ गए हैं या केवल स्थैतिक पृष्ठों की सेवा कर रहे हैं

आपके पास अपने वेब सर्वर पर एक निश्चित निर्देशिका संरचना है और केवल स्थिर फाइलें जैसे छवियां, HTML और इतने पर - कोई सर्वर साइड स्क्रिप्ट या जो भी।

एक ब्राउज़र अनुरोध /index.htm, यह मौजूद है और क्लाइंट को दिया जाता है। बाद में आपके पास बहुत सारे हैं - मान लीजिए कि डीवीडी फिल्मों की समीक्षा की गई है और /dvd/निर्देशिका में उनमें से प्रत्येक के लिए एक html पृष्ठ है । अब कोई अनुरोध करता है /dvd/adams_apples.htmऔर इसे वितरित किया जाता है क्योंकि यह वहां है।

किसी दिन, कोई व्यक्ति केवल अनुरोध करता है /dvd/- जो एक निर्देशिका है और सर्वर यह पता लगाने की कोशिश कर रहा है कि क्या वितरित करना है। उपयोग प्रतिबंध के अलावा और इतने पर वहाँ दो संभावनाएं हैं: उपयोगकर्ता निर्देशिका सामग्री दिखाएं (मुझे यकीन है कि आप पहले से ही इस कहीं देखा है) या एक डिफ़ॉल्ट फ़ाइल दिखाने (अपाचे में यह है: DirectoryIndex: sets the file that Apache will serve if a directory is requested.)

अब तक बहुत अच्छा, यह अपेक्षित मामला है। यह पहले से ही हैंडलिंग में अंतर दिखाता है, तो चलिए इसे देखते हैं:

सुबह 5:34 पर आपने अपनी फाइलें अपलोड करने में गलती की

(जो कि पूरी तरह से समझने योग्य है।) तो, आपने कुछ गलत किया और अपलोड करने के बजाय /dvd/the_big_lebowski.htm आपने उस फ़ाइल को dvd(बिना एक्सटेंशन के) के रूप में अपलोड किया /।

किसी ने आपका बुकमार्क कर दिया /dvd/ निर्देशिका सूची को कर लिया (बेशक आप उस निफ्टी को बनाना और हमेशा अपडेट नहीं करना चाहते थे index.htm) और आपकी वेब-साइट पर जा रहे हैं। निर्देशिका सामग्री वितरित की जाती है - सभी ठीक।

किसी ने आपकी सूची के बारे में सुना और टाइप कर रहा है /dvd । और अब यह खराब हो गया है। आपके डीवीडी डायरेक्टरी को सूचीबद्ध करने के बजाय सर्वर उस नाम से एक फाइल ढूंढता है और आपकी बिग लेबोव्स्की फाइल डिलीवर करता है।

इसलिए, आप उस फ़ाइल को हटा देते हैं और उस व्यक्ति को पृष्ठ पुनः लोड करने के लिए कहते हैं। आपका सर्वर /dvdफ़ाइल की तलाश करता है, लेकिन यह चला गया है। तब अधिकांश सर्वर यह नोटिस करेंगे कि उस नाम के साथ कोई निर्देशिका है और क्लाइंट को बताएं कि वह जो देख रहा था वह वास्तव में कहीं और है। प्रतिक्रिया सबसे अधिक संभावना होगी:

Status Code:301 Moved Permanently साथ में Location: http://[...]/dvd/

इसलिए, निर्देशिकाओं या फ़ाइलों के बारे में आपके विचार से पूरी तरह से अनदेखा करना , सर्वर केवल ऐसे सामान को संभाल सकता है और - जब तक कि अलग-अलग नहीं बताया जाता है - आपके लिए "स्लेश या नहीं" के अर्थ के बारे में निर्णय लेता है।

अंत में यह प्रतिक्रिया प्राप्त करने के बाद, क्लाइंट लोड हो जाता है /dvd/और सब कुछ ठीक हो जाता है।

यह ठीक है? नहीं।

"बस ठीक है" आपके लिए बहुत अच्छा नहीं है

आपके पास कुछ डायनामिक पेज हैं जहां सब कुछ पास /index.phpहो जाता है और संसाधित हो जाता है। अब तक सब कुछ काफी अच्छा था, लेकिन यह पूरी बात धीमी लग रही है और आप जांच करते हैं।

जल्द ही, आप देखेंगे कि जो /dvd/listबिल्कुल वैसा ही कर रहा है: /dvd/list/जिसे फिर से आंतरिक रूप से अनुवादित किया गया है index.php?controller=dvd&action=list। एक अतिरिक्त अनुरोध - लेकिन इससे भी बदतर! customer/loginरीडायरेक्ट करने के लिए customer/login/जो बदले में HTTPS URL के रीडायरेक्ट करता है customer/login/। आप अंत में टन कर रहे हैं अनावश्यक HTTP पुनर्निर्देश (= अतिरिक्त अनुरोध) के हैं जो उपयोगकर्ता के अनुभव को धीमा बनाते हैं।

सबसे अधिक संभावना है कि आपके पास यहां एक डिफ़ॉल्ट निर्देशिका सूचकांक भी है: index.php?controller=dvdबिना किसी actionआंतरिक भार के index.php?controller=dvd&action=list।

सारांश:

इसके साथ समाप्त होता है /यह कर सकते हैं कभी नहीं एक फाइल हो। कोई सर्वर अनुमान नहीं लगा रहा है।
स्लैश या नो स्लैश पूरी तरह से अलग अर्थ हैं। "स्लैश या स्लैश नहीं" के बीच एक तकनीकी / संसाधन अंतर है, और आपको इसके बारे में पता होना चाहिए और तदनुसार इसका उपयोग करना चाहिए। सिर्फ इसलिए कि सर्वर सबसे अधिक संभावना रखता है /dvd/index.htm- या सही स्क्रिप्ट सामान लोड करता है - जब आप कहते हैं /dvd: यह ऐसा करता है, लेकिन इसलिए नहीं कि आपने सही अनुरोध किया है। जो होता /dvd/।
यदि आप वास्तव में स्लैश किए गए संस्करण का अर्थ है , तो स्लैश को छोड़ना आपको अतिरिक्त HTTP अनुरोध जुर्माना देता है। जो हमेशा खराब होता है (मोबाइल विलंबता के बारे में सोचता है) और "सुंदर URL" से अधिक वजन होता है - विशेषकर चूंकि क्रॉलर उतने गूंगे नहीं होते जितने कि एसईओ मानते हैं या आप विश्वास करना चाहते हैं;)

— निको गवांडे
स्रोत

2

तो अंत में स्लैश जोड़ने के लिए आप सभी संक्षेप में हैं? :)

— डेनिस

2

जब आप इसका अर्थ करते हैं, तो मैं इसका उपयोग करने के लिए हूं; उदाहरण के लिए नियंत्रकों और कार्यों की बात करना यह होगा: नियंत्रकों को स्लैश के साथ समाप्त होना चाहिए। जब आप किसी फ़ाइल या एक्शन का संदर्भ लेते हैं, तो स्लैश छोड़ें

— nico gawenda

रुको, आप एक कार्रवाई के लिए स्लैश को क्यों छोड़ देंगे? आपके उदाहरण के अनुसार, क्या इसका परिणाम अतिरिक्त पुनर्निर्देशित अनुरोध नहीं है? मेरा मतलब है, संभवतः आपका सर्वर एक नियंत्रक कार्रवाई को पहचानने के लिए पर्याप्त स्मार्ट है और वास्तव में उस मामले में फ़ाइलों या निर्देशिकाओं को देखने के लिए पुनर्निर्देशित नहीं करेगा, लेकिन यह अभी भी आपके उदाहरण के खिलाफ जाता है?

— एडम गुडविन

7

मैं आपके उदाहरण को नहीं समझता। क्या फाइलसिस्टम एक निर्देशिका और उसी नाम के साथ एक और नियमित फाइल की अनुमति देता है dvd?

— मुशीफिल

19

अपना URL बनाने /about-us/(स्लैश के साथ), यह एक एकल फाइल के साथ शुरू करना आसान है index.htmlबाद में और फिर इसे बढ़ा सकते हैं और फ़ाइलें (जैसे जोड़ने our-CEO-john-doe.jpg) या यहाँ तक कि यह (जैसे के तहत एक पदानुक्रम का निर्माण /about-us/company/, /about-us/products/,, आदि) के रूप में की जरूरत के बिना प्रकाशित URL को बदलना । इससे आपको एक बेहतरीन लचीलापन मिलता है।

— musiphil
स्रोत

9

मुझे खेद है कि मुझे यह नहीं मिला। अगर मैं शुरू करता हूं /about-usया /about-us/मुझे अभी भी दोनों मामलों में प्रकाशित URL को बदलना होगा यदि मैंने निर्देशिका का विस्तार किया है। /about-us/new-file.htmlदोनों मामलों में नई फाइल होगी !! मुझे यहां क्या समझ नहीं आ रहा है?

— लेखाकार م

2

@ मुझे लगता है कि ओपी सोच रहा होगा कि यदि आप "/ अबाउट-अस" प्रकाशित करते हैं तो बिना किसी स्लैश के तो आप बाद में सापेक्ष पथों का उपयोग करके उप-संसाधन नहीं जोड़ सकते। जब आपके पास अनुगामी स्लेश नहीं है तो ब्राउज़र "ceo.jpg" के संदर्भ में विश्वास करेगा कि पृष्ठ के बारे में आपके डोमेन के मूल में रहेगा और example.com/ceo.jpg का अनुरोध करेगा। स्लैश के साथ, ब्राउजर example.com/about-us/ceo.jpg का अनुरोध करेगा और जैसे-जैसे आप विस्तार करेंगे, आप वैधानिक रूप से आपकी साइट के लिए फ़ोल्डरों का एक पूरा ट्री रूट कर सकते हैं।

— दाऊ

1

FYI करें - मुझे विश्वास नहीं है कि उपरोक्त में से कोई भी सत्य है - एक /about-usऔर क्यों नहीं हो सकता है /about-us/company? फ़ाइलों की सेवा करने के मामले में, Apache और IIS दोनों ही इसे ठीक कर सकते हैं, इसलिए मैं असहमत हूं।

— शॉन 2078

1

@ sean2078 हां, लेकिन अगर, /about-usआप से लिंक करना चाहते हैं /about-us/company, तो आपको उपयोग करना होगा href="https://stackoverflow.com/about-us/company"या href="./company"(उस एक के बारे में निश्चित नहीं है, हालांकि)। यदि आप पर हैं /about-us/, हालांकि, यह आसान है href="company":।

— Adowrath

11

अन्य उत्तर यहाँ अनुगामी स्लेश को छोड़ देने के पक्ष में प्रतीत होते हैं। एक मामला है जिसमें एक अनुगामी स्लैश खोज इंजन अनुकूलन (एसईओ) के साथ मदद करेगा। यही स्थिति है कि आपके दस्तावेज़ में वह फ़ाइल एक्सटेंशन है जो ऐसा नहीं है .html। यह उन साइटों के साथ एक मुद्दा बन जाता है जो रेटिंग वेबसाइट हैं। वे इन दो url के बीच चयन कर सकते हैं:

http://mysite.example.com/rated.example.com
http://mysite.example.com/rated.example.com/

ऐसे मामले में, मैं अनुगामी स्लैश के साथ एक को चुनूंगा । वह इसलिए कि.com विस्तार विंडोज निष्पादन योग्य कमांड फ़ाइलों के लिए एक एक्सटेंशन है। खोज इंजन और वायरस चेकर्स अक्सर ऐसे URL को नापसंद करते हैं जो यह प्रकट करते हैं कि उनमें ऐसे तंत्र के माध्यम से वितरित मैलवेयर हो सकते हैं। अनुगामी स्लैश किसी भी चिंताओं को कम करने के लिए लगता है, जिससे पृष्ठ को खोज इंजन में रैंक करने और वायरस चेकर्स द्वारा प्राप्त करने की अनुमति मिलती है।

यदि आपके URL .में फ़ाइल भाग नहीं है, तो मैं सरलता के लिए अनुगामी स्लैश को छोड़ने की सलाह दूंगा।

— स्टीफन ओस्टरमिलर
स्रोत

कोई वास्तविक खोज इंजन उस बेवकूफ नहीं हैं। यह जवाब शुद्ध अटकलें हैं।

— नवीन

1

मैंने वास्तव में इस मुद्दे को Google के साथ देखा है। यह कई साल पहले था, इसलिए मुझे यकीन नहीं है कि आज भी ऐसा ही होगा।

— स्टीफन ओस्टरमिलर

हुह, यह एक अच्छा डेटा बिंदु है। हालांकि हम अभी भी नहीं जानते हैं कि यह किसी और चीज के कारण हुआ था।

— नवीन

10

कौन कहता है कि फ़ाइल नाम को एक्सटेंशन की आवश्यकता है ?? कभी-कभी एक * निक्स मशीन पर एक नज़र डालें ...
मैं आपके दोस्त से सहमत हूं, कोई अनुगामी स्लैश नहीं।

— हारून गज़
स्रोत

3

एक एसईओ परिप्रेक्ष्य से, यह चुनना कि URL के अंत में एक अनुगामी स्लैश शामिल करना है या नहीं, अप्रासंगिक है। इन दिनों, वेब पर दोनों के उदाहरण देखना आम है। किसी भी तरह से साइट को दंडित नहीं किया जाएगा, न ही यह विकल्प आपकी वेबसाइट की खोज इंजन रैंकिंग या अन्य एसईओ विचारों को प्रभावित करेगा।

बस एक URL नामकरण सम्मेलन चुनें जिसे आप पसंद करते हैं, और इसमें एक कैनोनिकल मेटा टैग शामिल करें <head> प्रत्येक वेबपेज अनुभाग शामिल करें।

खोज इंजन एकल वेबपृष्ठ को दो अलग-अलग डुप्लिकेट URL के रूप में मान सकते हैं, जब वे अनुगामी स्लैश के साथ और उसके बिना, example.com/about-us/औरexample.com/about-us ।

प्रत्येक पृष्ठ पर एक कैनॉनिकल मेटा टैग को शामिल करना सबसे अच्छा अभ्यास है क्योंकि आप यह नियंत्रित नहीं कर सकते हैं कि अन्य साइटें आपके URL से कैसे लिंक होती हैं।

विहित टैग इस तरह दिखता है: <link rel="canonical" href="https://example.com/about-us" />। एक विहित मेटा टैग का उपयोग यह सुनिश्चित करता है कि खोज इंजन आपके प्रत्येक URL को केवल एक बार गिनता है, भले ही अन्य वेबसाइटें आपकी साइट से लिंक करते समय एक अनुगामी स्लैश शामिल हों।

— दंगा
स्रोत