होना या न होना ... क्या मुझे अपने डोमेन पर www का उपयोग करना चाहिए?

20 साल या उससे अधिक समय से, आपकी वेबसाइट के कैनॉनिकल होस्ट नाम (CNAME) में www का उपयोग करने की चर्चा है। तो क्या उपयोग करें या नहीं?



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

आपके लिए, एक IT व्यवस्थापक के रूप में, आपका डोमेन आपका नेटवर्क होगा। डोमेन को एक नाम देना उचित है। DNS सिस्टम इसके लिए अनुकूलित है, इसलिए आप एक डोमेन नाम पंजीकृत करते हैं, उदाहरण के लिए, example.com । अब, इस डोमेन के अंतर्गत आपके पास अपने मेजबान होंगे। नेटवर्क कनेक्शन वाली प्रत्येक मशीन को एक मेजबान माना जाता है। WWW दस्तावेज़ सर्विसिंग मशीन स्वाभाविक रूप से आपके डोमेन में होस्ट नाम www प्राप्त करेगी, इसलिए इसका पूरी तरह से योग्य डोमेन नाम (FQDN) www.example.com होगा। आप अपने नेटवर्क पर बाकी मेजबानों के लिए भी ऐसा ही करेंगे, चाहे आपके पास वेब सर्वर हो या न हो। इसलिए आप अपने नेटवर्क को साफ करें।

example.com डोमेन में वेब सर्वर पर जाने के लिए, आपको www.example.com नाम के होस्ट पर जाना चाहिए। वैसे, उन दिनों में जब डायनासोर वेब पर घूमते थे, आभासी मेजबान मौजूद नहीं थे। प्रत्येक वेब सर्वर ने केवल एक वेबसाइट (कम से कम एक आईपी पते) पर काम किया। यदि यह सही IP पते की ओर इशारा करता है, तो होस्ट नाम कोई मायने नहीं रखता।

"नंगे डोमेन नाम", अर्थात DNS के बिना, example.com रूप में, 'www' के बिना एक डोमेन नाम को मूल कहा जाता है। 1990 के दशक के मध्य में जब वर्ल्ड वाइड वेब की लोकप्रियता बढ़ी, तो कुछ प्रशासक उसी IP पते को मूल रूप से www होस्ट के रूप में निर्दिष्ट करने लगे। यह वेबसाइट आगंतुकों को पूरी तरह से योग्य होस्ट नाम के बजाय ब्राउज़र में सिर्फ example.com दर्ज करने की अनुमति देता है।

फिर SEO आया

चूंकि example.com और www.example.com अलग-अलग आईपी पते की ओर इशारा कर सकते हैं, और जनवरी 1997 से एक ही आईपी पते पर अलग-अलग वेबसाइटों के लिए, एसईओ विशेषज्ञों ने हमें बताना शुरू कर दिया कि हमें एक कैनोनिकल होस्ट नाम और बाकी का चयन करना चाहिए। वहाँ इंगित करना चाहिए (HTTP स्थिति कोड 301 के साथ)।

यह एक नाम चुनने के लिए समझ में आया। लेकिन कौन सा? एसईओ के लिए, यह वास्तव में कोई फर्क नहीं पड़ता। मुख्य बात एक है। लेकिन SEO के अलावा और भी समस्याएं हैं। पर पढ़ें।

लोग URL को कैसे समझते हैं

जब मैंने सदी के मोड़ पर एक मार्केटिंग एजेंसी में काम किया, तो मुझे चिंता हुई कि लोग यह न समझें कि उनके सामने वर्ल्ड वाइड वेब का पता है अगर हम 'www' भाग को छोड़ देते हैं। मेरा मतलब है, हमने अभी "http: //" स्किप करना शुरू किया है। इसके अलावा, ऐतिहासिक कारणों से, मैंने व्यक्तिगत रूप से पूर्ण "सही" होस्ट नाम का उपयोग करने के लिए चुना, अर्थात। www.example.com

आज मुझे नहीं लगता कि यह महत्वपूर्ण है। लोग समझेंगे कि यह एक वेब पता है, चाहे www वहाँ है या नहीं, जब उनके सामने एक प्रसिद्ध शीर्ष-स्तरीय डोमेन है। चूँकि एक संस्करण अभी भी दूसरे पर पुनर्निर्देशित होता है, इससे कोई फर्क नहीं पड़ता कि आपका कैनोनिकल होस्ट नाम www.example.com , और आप सुंदरता के लिए केवल प्रिंट विज्ञापनों के लिए example.com उपयोग करते हैं। उसी समय, यदि आपके पास .beer जैसे हजारों नए शीर्ष-स्तरीय डोमेन हैं, तो यह उन्हीं कारणों से www जोड़ने के लिए समझ में आता है, जो आपने सदी के मोड़ पर विपणन में किए थे।

Www के बिना यह सरल और अधिक सुंदर है

मुझे स्वीकार करना चाहिए: example.com टाइप करना अधिक आसान है, पढ़ने में आसान है, और यह केवल बचत स्थान है। यह समझ में आता है कि लोग www को छोड़ना शुरू कर देते हैं - और मूल को विहित मेजबान नाम के रूप में निर्दिष्ट करते हैं।

तो वे अभी भी इस बारे में बहस क्यों कर रहे हैं?

हम अभी भी 'www' के उपयोग पर चर्चा क्यों कर रहे हैं या नहीं? सभी को वह उपयोग करने दें जो वह चाहता है, क्या यह संभव नहीं है?

बेशक आप कर सकते हैं।

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

कुकीज़ उपडोमेन को पारित कर रहे हैं

होस्ट की ओर से सेट किए गए कुकीज़ सभी उप-डोमेन के लिए भी सेट किए जाएंगे। यही है, अगर example.com पर साइट एक कुकी सेट करती है, तो www.example.com पर जाने पर ब्राउज़र इस फ़ाइल को भी भेजेगा। अच्छा लगता है, यह वही साइट है, है ना? लेकिन कुकीज़ cdn.example.com , email.example.com , intranet.example.com , thirdpartyservice.example.com आदि पर भी जाएंगे। और कई तृतीय-पक्ष सेवाएँ आपको इस तरह से अपने डोमेन का उपयोग करने की अनुमति देती हैं।

होस्ट www.example.com * से सेट किया गया कुकी उपर्युक्त किसी भी "भाई" होस्ट को नहीं भेजा जाएगा। आपका ब्राउज़र समझता है कि ये "सबस्क्राइबर" नहीं हैं, लेकिन पूरी तरह से अलग सेवाएँ हैं जो आपके कुकीज़ तक नहीं पहुँचनी चाहिए।

अनावश्यक कुकीज़ चोट प्रदर्शन

HTTP और कुकीज के काम करने का तरीका यह है कि वे वेब सर्वर पर प्रत्येक अनुरोध के साथ ब्राउज़र से भेजे जाते हैं। इसका मतलब यह है कि यदि आपकी साइट उत्पत्ति के लिए कुकीज़ सेट करती है (example.com) तो यह फ़ाइल आपके द्वारा किए गए प्रत्येक अनुरोध के लिए भी भेजी जानी चाहिए, उदाहरण के लिए, email.example.com या intranet.example.com । इससे कनेक्शन धीमा हो जाता है।

कुकीज़ को तीसरे पक्ष द्वारा पढ़ा जा सकता है

इसलिए, यदि वेबसाइट मूल (example.com) के समान है और CMS सिस्टम का उपयोग करता है, तो प्राधिकरण के बाद यह सत्र को खुला रखने के लिए आपके ब्राउज़र को कुकीज़ जारी करेगा। फिर, जब आप someinternalservice.example.com पर someinternalservice.example.com , तो इस सेवा का व्यवस्थापक इस कुकी को पढ़ सकता है, इसकी प्रतिलिपि बना सकता है और अपनी ओर से example.com लिए कॉर्पोरेट CMS में लॉग इन करने के लिए इसका उपयोग कर सकता है। ईमेल विक्रेता पर जाने के दौरान भी email.example.com ई-मेल विक्रेता पर लागू होती है। वह सीडीएन प्रदाता है जो संसाधनों को डाउनलोड करता है, जैसे कि static.example.com , और इसी तरह।

यदि आप example.com पर कम से कम कुछ की सुरक्षा के बारे में चिंतित हैं, तो इससे पहले 'www' को शामिल करना सुनिश्चित करें। यहां तक ​​कि अगर यह आपको 'www' का उपयोग करने के लिए मना नहीं करता है, तो मुझे नहीं पता कि यह क्या मना सकता है। न तो HTTPS और न ही 2FA मदद करेगा, क्योंकि यह कुकी एक जादू टोकन है। हालांकि, अन्य सुरक्षा उपाय, जैसे कि आईपी ​​प्रतिबंध , मदद कर सकते हैं।

यदि आप चाहें तो उप-डोमेन से कुकीज़ साझा की जा सकती हैं

यदि आपके पास उपडोमेन पर एक सेवा है, उदाहरण के लिए, sso.example.com , तो RFC 6265 आपको मूल के लिए कुकीज़ सेट करने और example.com या www.example.com साथ इसे सामान्य बनाने की अनुमति देता है। इस प्रकार, मेजबान नाम के रूप में "नंगे डोमेन" को छोड़ना, वास्तव में, आपको अधिक लचीलापन देता है।

डीएनएस प्रतिबंध

लचीलेपन की बात करें तो हमें DNS के बारे में बात करने की जरूरत है।

DNS में एक सीमा है कि मूल एक A रिकॉर्ड होना चाहिए, जो कि एक निश्चित IP पते की ओर इशारा करता है।

जब आपकी साइट बड़ी हो जाती है और आप इसे होस्ट करने के लिए स्थानांतरित करते हैं या इसे फ़ायरवॉल या DDoS सुरक्षा सेवा में निर्देशित करना चाहते हैं, तो CNAME रिकॉर्ड का उपयोग होस्ट नाम को किसी अन्य असंगत होस्ट नाम को निर्देशित करने के लिए करें, जिसे प्रदाता आपके ट्रैफ़िक और आवश्यकताओं के आधार पर नियंत्रित करता है।

लेकिन अगर साइट को एक नंगे डोमेन (उदाहरण.कॉम) पर होस्ट किया जाता है, तो आप ऐसा नहीं कर सकते। हालाँकि, CNAME में 'www' के साथ होस्ट नाम निर्दिष्ट करने में कोई समस्या नहीं है। इसलिए, यदि आप भविष्य में या भविष्य में किसी भी स्केलेबिलिटी चाहते हैं, तो आपको शुरू से ही होस्ट नाम 'www' से सेट करना चाहिए।

निष्कर्ष: www चुनें

यह महत्वपूर्ण है कि आप www का उपयोग करते हैं या नहीं। मैं मानता हूं कि नंगे डोमेन पहले से दिखते हैं, लेकिन यह ब्राउज़र एड्रेस बार के लिए सिर्फ एक व्यावहारिक प्रश्न है। आप www.example.com को विहित होस्ट नाम के रूप में उपयोग कर सकते हैं, और अन्य स्थानों पर बस नंगे डोमेन का उपयोग कर सकते हैं। उपयोगकर्ताओं को अभी भी जहाँ आवश्यक हो पुनर्निर्देशित किया जाएगा।

लेकिन महत्वपूर्ण तर्क 'www' के साथ पूरी तरह से योग्य होस्ट नाम का उपयोग करने के पक्ष में बोलते हैं: प्रदर्शन, सुरक्षा और लचीलेपन के लिए।

इसलिए एक बार और सभी के लिए चर्चा को समाप्त कर दें: 'www' को चुनें!