במשך שנים משתוללת בסרגלי הכתובות שלנו מלחמת פדנטיות קטנה. בפינה אחת נמצאים מותגים כמו Google, אינסטגרם`, ו פייסבוק. קבוצה זו בחרה להפנות מחדש example.com ל www.example.com. בפינה הנגדית: GitHub, DuckDuckGo, ו מחלוקת. קבוצה זו בחרה לעשות הפוך ולהפנות מחדש www.example.com ל example.com.
האם "WWW" שייך לכתובת אתר? חלק מהמפתחים מחזיקים בדעות נחרצות בנושא. נחקור טיעונים בעד ונגד זה לאחר קצת היסטוריה.
מה הקשר ל-Ws?
שלושת ה-W מייצגים "אינטרנט", המצאה של סוף שנות ה-1980 שהציגה לעולם את הדפדפנים ואתרי האינטרנט. הנוהג של שימוש ב-"WWW" נובע ממסורת של מתן שמות של תת-דומיינים על פי סוג השירות שהם מספקים:
- שרת אינטרנט ב www.example.com
- שרת FTP ב ftp.example.com
- שרת IRC ב irc.example.com
דאגה לדומיין ללא WWW 1: דליפת קובצי Cookie לתת-דומיינים
מבקרים של תחומים "נטולי WWW" ציינו שבמצבים מסוימים, תת-דומיין.example.com יוכל לקרוא עוגיות שהוגדרו על ידי example.com. זה עשוי להיות לא רצוי אם, למשל, אתה ספק אירוח אתרים המאפשר ללקוחות להפעיל תת-דומיינים בדומיין שלך. למרות שהחשש תקף, ההתנהגות הייתה ספציפית ל-Internet Explorer.
RFC 6265 תקן את האופן שבו דפדפנים מתייחסים לקובצי Cookie וקורא במפורש התנהגות זו כשגויה.
מקור פוטנציאלי נוסף לדליפות הוא Domain ערך של קובצי Cookie שהוגדרו על ידי example.com. אם Domain הערך מוגדר במפורש ל example.com, קובצי ה-cookie יהיו חשופים גם לתת-הדומיינים שלו.
| ערך קוקי | נחשף ל example.com | נחשף ל תת-דומיין.example.com |
|---|---|---|
secret=data |
✅ | ❌ |
secret=data; Domain=example.com |
✅ | ✅ |
לסיכום, כל עוד אתה לא קובע במפורש א Domain ערך והמשתמשים שלך אינם משתמשים ב-Internet Explorer, לא אמורות להתרחש דליפות של קובצי Cookie.
דאגה 2 ללא WWW: כאבי ראש DNS
לפעמים, דומיין "ללא WWW" עלול לסבך את הגדרת מערכת שמות הדומיין (DNS) שלך.
כאשר משתמש מקליד example.com בשורת הכתובת של הדפדפן שלהם, הדפדפן צריך לדעת את כתובת פרוטוקול האינטרנט (IP) של שרת האינטרנט שבו הם מנסים לבקר. הדפדפן מבקש כתובת IP זו משרתי השמות של הדומיין שלך - בדרך כלל בעקיפין דרך שרתי ה-DNS של ספק האינטרנט של המשתמש (ISP). אם שרתי השמות שלך מוגדרים להגיב עם הקלטה המכיל את כתובת ה-IP, דומיין "ללא WWW" יעבוד מצוין.
במקרים מסוימים, ייתכן שתרצה במקום זאת להשתמש ב-a שם קנוני (CNAME) שיא עבור האתר שלך. רישום כזה יכול להכריז על כך www.example.com הוא כינוי של example123.somecdnprovider.com, שאומר לדפדפן המשתמש לחפש במקום זאת את כתובת ה-IP של example123.somecdnprovider.com ולשלוח לשם את בקשת ה-HTTP.
שימו לב שהדוגמה שלמעלה השתמשה בתת-דומיין של WWW. לא ניתן להגדיר עבור רשומת CNAME example.com. לפי RFC 1912, רשומות CNAME אינן יכולות להתקיים יחד עם רשומות אחרות. אם ניסית להגדיר רשומת CNAME עבור example.com, רשומות שרת השמות (NS) עבור example.com המכילים את כתובות ה-IP של שרתי השמות של הדומיין לא יורשו להתקיים. כתוצאה מכך, דפדפנים לא יוכלו להבין היכן נמצאים שרתי השמות שלך.
ספקי DNS מסוימים יאפשרו לך לעקוף מגבלה זו. Cloudflare קורא לפתרון שלהם שיטוח CNAME. בטכניקה זו, מנהלי תחום מגדירים רשומת CNAME, אך שרתי השמות שלהם יחשפו רשומת A.
לדוגמה, אם מנהל המערכת מגדיר רשומת CNAME עבור example.com מצביע על example123.somecdnprovider.com, ושיא A עבור example123.somecdnprovider.com קיים מצביע על 1.2.3.4, ואז Cloudflare יחשוף שיא A עבור example.com מצביע על 1.2.3.4.
לסיכום, בעוד שהחשש תקף עבור בעלי דומיינים המעוניינים להשתמש ברשומות CNAME, ספקי DNS מסוימים מציעים כעת פתרון מתאים.
הטבות ללא WWW
רוב ויכוח נגד WWW הם פרקטיים או קוסמטיים. תומכי "לא-WWW" טענו שקל יותר לומר ולהקליד example.com מֵאֲשֶׁר www.example.com (מה שעשוי להיות פחות מבלבל עבור משתמשים פחות מביני טכנולוגיה).
מתנגדי תת-הדומיין של WWW גם ציינו שביטולו מגיע עם יתרון ביצועים צנוע. בעלי אתרים יכולים לגלח 4 בתים מכל בקשת HTTP על ידי כך. למרות שהחיסכון הזה יכול להצטבר לאתרים בעלי תנועה גבוהה כמו פייסבוק, רוחב פס בדרך כלל אינו משאב נדיר.
הטבות WWW
טיעון מעשי אחד בעד WWW הוא במצבים עם תחומים חדשים יותר ברמה העליונה. לדוגמה, www.example.miami ניתן לזהות מיד ככתובת אינטרנט כאשר example.miami לא. זה פחות מדאיג אתרים שיש להם דומיינים ברמה עליונה מוכרים כמו .com.
השפעה על דירוג מנוע החיפוש שלך
הקונצנזוס הנוכחי הוא שהבחירה שלך אינה משפיעה על הביצועים של מנוע החיפוש שלך. אם ברצונך לעבור מאחד לשני, תרצה להגדיר הפניות מחדש קבועות (HTTP 301) במקום זמניות (HTTP 302). הפניות קבועות מבטיחות שערך ה-SEO של כתובות האתרים הישנות שלך יועבר לכתובות החדשות.
טיפים לתמיכה בשניהם
אתרים בדרך כלל בוחרים גם example.com or www.example.com כאתר הרשמי שלהם ולהגדיר הפניות HTTP 301 עבור האחר. בתיאוריה, אפשר לתמוך בשניהם www.example.com ו example.com. בפועל, העלויות עשויות לעלות על התועלת.
מנקודת מבט טכנית, תרצה לוודא שהמחסנית הטכנולוגית שלך יכולה להתמודד עם זה. מערכת ניהול התוכן (CMS) או האתר שנוצר באופן סטטי יצטרכו להוציא קישורים פנימיים ככתובות URL יחסיות כדי לשמר את שם המארח המועדף על המבקר. כלי הניתוח שלך עשויים לרשום תנועה לשני שמות המארחים בנפרד, אלא אם כן תוכל להגדיר את שמות המארחים ככינויים.
לבסוף, תצטרך לנקוט צעד נוסף כדי לשמור על הביצועים של מנוע החיפוש שלך. Google תחשב את גרסאות ה-"WWW" וה-"לא-WWW" של כתובת אתר תוכן משוכפל. כדי לבטל כפילות של תוכן באינדקס החיפוש שלה, גוגל תציג את מה מהשניים שלדעתה המשתמש יעדיף - לטוב ולרע.
כדי לשמור על שליטה על האופן שבו אתה מופיע בגוגל, הוא ממליץ להכניס תגיות קישור קנוניות. ראשית, החליטו איזה שם מארח יהיה הרשמי (הקנוני).
לדוגמה, אם אתה בוחר www.example.com, תצטרך להוסיף את הקטע הבא ב- תתיג https://example.com/my-article:
קטע זה מציין לגוגל שהגרסה "ללא WWW" מייצגת את אותו תוכן. באופן כללי, Google תעדיף את הגרסה שסימנת כקנונית בתוצאות החיפוש, שתהיה הגרסה "WWW" בדוגמה זו.
סיכום
למרות קמפיין אינטנסיבי משני הצדדים, שתי הגישות נשארות בתוקף כל עוד אתה מודע ליתרונות ולמגבלות. כדי לכסות את כל הבסיסים שלך, הקפד להגדיר הפניות קבועות מאחד לשני והכל מוכן.
