דומיין לחנות אונליין - למה הוא חשוב ואיך לבחור נכון

דומיין הוא אחד הדברים הראשונים שלקוח רואה לפני שהוא בכלל נכנס לחנות. הוא מופיע בגוגל, בקישורים שמשתפים ב-WhatsApp, בפרסומות, באימיילים ועל חומרי שיווק. בגלל זה הוא לא רק כתובת טכנית אלא חלק מהמותג ומהאמון שהחנות יוצרת.

עסק יכול להתחיל לעבוד על חנות עוד לפני שחיבר דומיין, אבל ברגע שמתחילים לשלוח לקוחות אמיתיים לאתר, כדאי לעבור לכתובת עצמאית ששייכת לעסק. שימוש בדומיין של הפלטפורמה או בכתובת זמנית יכול להיות נוח לפיתוח, אבל פחות מתאים לנכס מסחרי ארוך טווח.

בחירה טובה אינה דורשת שם מתוחכם. ברוב המקרים דווקא שם פשוט, ברור וקל לזכירה עובד טוב יותר. המטרה היא שאדם ששמע את שם העסק פעם אחת יוכל להקליד את הכתובת בלי לנחש.

דומיין הוא נכס של העסק

החנות יכולה לעבור בעתיד בין מערכות, ספקי אחסון או פלטפורמות. הדומיין אמור להישאר בבעלות העסק לאורך כל הדרך.

לכן חשוב לרשום אותו בחשבון שבשליטת העסק, עם פרטי גישה ברורים ואמצעי שחזור שהבעלים יכול לנהל. לא מומלץ להשאיר את הבעלות בפועל אצל מפתח, סוכנות או אדם שכבר לא יהיה חלק מהעסק בעתיד.

שם קצר בדרך כלל קל יותר לזכור

כל תו נוסף מגדיל את הסיכוי לטעות. שם קצר יחסית, שקל לומר בקול ולכתוב, הופך את הדומיין לשימושי יותר בפרסום ובשיחות עם לקוחות.

אין צורך לקצר בכוח אם התוצאה אינה ברורה, אבל כדאי להימנע משמות ארוכים מאוד שמחייבים את הלקוח לזכור כמה מילים ברצף.

הדומיין צריך להיות קל לאיות

אם צריך להסביר בכל פעם איך מאייתים את הכתובת, זה סימן שהשם עלול ליצור חיכוך. שמות שבהם יש כמה אפשרויות כתיב, מספרים במקום מילים או משחקי אותיות מורכבים יכולים לגרום לאנשים להגיע לכתובת הלא נכונה.

בדקו את השם גם בטלפון: אמרו אותו לאדם אחר ובקשו ממנו לכתוב את הדומיין כפי ששמע. זו בדיקה פשוטה שיכולה לחשוף בעיה במהירות.

מותג קודם בדרך כלל למילת מפתח

בעבר היה נפוץ לבחור דומיינים שמורכבים כמעט רק ממילות חיפוש. היום אין צורך לדחוס את כל תחום הפעילות לכתובת.

דומיין שמתאים לשם העסק קל יותר לבניית מותג. SEO יכול לעבוד מצוין גם כאשר מילות המפתח נמצאות בעמודים, בקטגוריות, בכותרות ובתוכן ולא בשם הדומיין עצמו.

מילת מפתח יכולה לעזור בהבנה אבל לא צריך להכריח אותה

אם שם העסק כבר כולל מילה שמתארת את התחום, זה יכול להיות טבעי. אבל הוספת כמה מילים רק בשביל SEO עלולה ליצור כתובת ארוכה ולא מקצועית.

העדיפות היא לדומיין שהלקוח יזהה וישתמש בו לאורך שנים.

איזו סיומת לבחור

הסיומת צריכה להתאים לקהל ולמותג. עסק שמכוון בעיקר לישראל יכול לשקול סיומת מקומית, בעוד מותג בינלאומי עשוי להעדיף סיומת גלובלית.

אין סיומת אחת שמתאימה לכל עסק. השיקולים המרכזיים הם זמינות, קהל יעד, אמון וזכירות.

• סיומת מקומית יכולה לחזק זיהוי עם שוק מסוים
• סיומת גלובלית יכולה להתאים לפעילות בינלאומית
• סיומות חדשות יכולות להיות זמינות יותר אבל פחות מוכרות לחלק מהלקוחות
• כדאי לבדוק גם את מחיר החידוש ולא רק מחיר הרשמה ראשוני

בדקו מה הקהל מצפה לראות

לקוח מקומי יכול להרגיש טבעי מאוד עם סיומת מוכרת במדינה שלו. מצד שני, מותג שמתכנן להתרחב למדינות שונות עשוי לרצות כתובת שקל להשתמש בה בכל השווקים.

הבחירה צריכה להתאים לתכנית העסקית ולא רק למה שהיה פנוי ברגע ההרשמה.

אל תבחרו דומיין רק כי הוא זול בשנה הראשונה

חלק מהרשמים מציעים מחיר נמוך מאוד לשנה הראשונה ועלות גבוהה בהרבה לחידוש. דומיין הוא בדרך כלל נכס לשנים, ולכן מחיר החידוש חשוב יותר מהנחת ההצטרפות.

בדקו גם עלויות נוספות כמו פרטיות, הגנה, transfer או שירותים שאינם בהכרח כלולים.

ודאו שהשם אינו פוגע במותג אחר

לפני השקעה בשם, כדאי לבדוק שהוא אינו זהה או דומה בצורה בעייתית למותג מוכר בתחום. דומיין פנוי אינו בהכרח אומר שמותר לבנות עליו מותג.

במקרה של שם מסחרי משמעותי כדאי לבצע בדיקה מתאימה של סימני מסחר וזכויות לפי השוק שבו העסק פועל.

בדקו גם רשתות חברתיות ושמות משתמש

אם שם העסק עדיין לא סופי, כדאי לבדוק האם ניתן להשתמש בשם דומה גם ב-Instagram, Facebook, TikTok, YouTube או ערוצים אחרים שרלוונטיים לעסק.

אין חובה שהכל יהיה זהה לחלוטין, אבל אחידות מקלה על לקוחות למצוא את המותג.

הימנעו ממקפים אם אין בהם צורך

מקף יכול להיות שימושי כאשר הוא משפר קריאות, אבל כמה מקפים יוצרים כתובת שקשה לומר ולזכור.

אם קיימת גרסה טבעית ללא מקף והיא זמינה, היא לרוב פשוטה יותר. בכל מקרה כדאי להשתמש רק במקף רגיל ולא בתווים דומים שקשה לזהות.

מספרים יכולים ליצור בלבול

כאשר שם מכיל מספר, לקוח ששומע אותו אינו תמיד יודע אם לכתוב ספרות או מילה. לדוגמה, 4 לעומת four או ארבע.

אם המספר הוא חלק מרכזי מהמותג זה יכול לעבוד, אבל כדאי להבין את tradeoff.

הימנעו מתווים מיוחדים ומבנים מסובכים

דומיין מסחרי צריך להיות פשוט להקלדה. תווים לא רגילים, מבנה ארוך או שילוב לא ברור של מילים מגדילים את הסיכוי לטעות.

אפשר להשתמש בדומיין בעברית אבל צריך לשקול שימושיות

דומיינים בינלאומיים יכולים לתמוך בתווים שאינם לטיניים, אבל מאחורי הקלעים הם מיוצגים בצורה טכנית אחרת. זה יכול לעבוד, אך בשיתופים, מערכות מסוימות ותמיכה טכנית לעיתים כתובת לטינית פשוטה נוחה יותר.

לעסק שפועל בעברית אין חובה שהדומיין עצמו יהיה בעברית. אפשר להשתמש בשם מותג לטיני ולשמור את כל החנות בעברית מלאה.

דומיין אחד צריך להיות הכתובת הראשית

גם אם העסק מחזיק כמה דומיינים, רצוי להגדיר כתובת canonical אחת שמייצגת את החנות. כל שאר הכתובות יכולות להפנות אליה כאשר זה מתאים.

כך לקוחות ומנועי חיפוש רואים גרסה עקבית ולא כמה עותקים של אותו אתר.

www או בלי www - שניהם יכולים לעבוד

מבחינה מיתוגית אפשר לבחור rapidstore.co.il או www.rapidstore.co.il כגרסה הראשית. אין חובה עקרונית לאחד מהם.

מה שחשוב הוא לבחור גרסה אחת, להפנות אליה את השנייה ולשמור canonical עקבי.

אל תשאירו את שתי הגרסאות כאתרים נפרדים

אם גם www וגם non-www מציגים את אותו תוכן ללא הפניה ו-canonical מתאים, נוצרת כפילות מיותרת.

הגדרה נכונה צריכה לגרום לכל גרסה משנית לעבור לכתובת הראשית.

HTTPS הוא חובה בחנות אונליין

החנות צריכה לעבוד ב-HTTPS עם certificate תקין. זה חשוב בכל אתר, ובמיוחד באתר שמנהל accounts, carts ו-checkout.

לקוח שרואה אזהרת אבטחה בדפדפן לא צריך להחליט האם האתר בכל זאת בטוח. הוא פשוט עלול לצאת.

SSL צריך להתחדש אוטומטית

במערכת מסחר מודרנית לא כדאי להסתמך על כך שבעל החנות יזכור לחדש certificate ידנית. תהליך הדומיין צריך לכלול provisioning וחידוש אוטומטי ככל האפשר.

מהו DNS ולמה צריך אותו

DNS הוא המנגנון שמחבר את שם הדומיין לשירותים שמאחוריו. כאשר מחברים דומיין לחנות, בדרך כלל צריך להוסיף רשומה אחת או יותר אצל ספק ה-DNS.

בעל העסק לא צריך להיות מומחה DNS, אבל כן צריך לדעת היכן הדומיין מנוהל ואיפה מוסיפים את הרשומות שהפלטפורמה מבקשת.

A, AAAA ו-CNAME הם סוגי רשומות נפוצים

ספק החנות יכול לבקש CNAME, רשומת A או מבנה אחר בהתאם לארכיטקטורה שלו. אין צורך לבחור לבד את סוג הרשומה - כדאי להשתמש בדיוק בערכים שהמערכת מספקת.

אל תשנו רשומות שאינן קשורות לחנות בלי להבין אותן

אותו DNS יכול לנהל גם אימייל, אימותים ושירותים אחרים. מחיקה של MX, TXT או רשומה אחרת רק כדי לנקות את המסך יכולה להפיל שירותים שלא קשורים לאתר.

בעת חיבור חנות כדאי להוסיף או לשנות רק את הרשומות הנדרשות.

DNS propagation אינו תמיד מיידי

שינוי DNS יכול להופיע אצל חלק מהמערכות במהירות ואצל אחרות מאוחר יותר בגלל caching ו-TTL.

לכן verification מיד לאחר השינוי יכול להיכשל גם כאשר ההגדרה נכונה. מערכת טובה צריכה להציג status ברור ולא לגרום למשתמש לחשוב שהדומיין אבד.

Verification צריך לבדוק את הדומיין בפועל

כאשר החנות מבקשת לחבר דומיין, השרת צריך לבדוק שהרשומות מצביעות למקום הנכון לפני סימון domain כפעיל.

לא כדאי לסמן דומיין active רק משום שהמשתמש לחץ על כפתור אימות.

SSL יכול לקחת זמן נוסף גם אחרי DNS

יכול להיות שה-DNS כבר תקין אך certificate עדיין בתהליך הנפקה. לכן כדאי להפריד בין DNS status לבין SSL status ולהציג את שלב החיבור בצורה ברורה.

הדומיין צריך להפוך לפעיל אוטומטית כשהכל מוכן

חוויית משתמש טובה היא: בעל העסק מזין דומיין, מקבל רשומות, מוסיף אותן, לוחץ verify והמערכת ממשיכה לבדוק DNS ו-SSL עד שהכתובת מוכנה.

אין סיבה לדרוש מהמשתמש לבצע פעולות טכניות נוספות אם התשתית יכולה לבצע אותן אוטומטית.

כתובות פנימיות צריכות להשתמש בדומיין הציבורי

לאחר שהחנות מחוברת לדומיין, קישורים ציבוריים צריכים להישאר תחת המותג של החנות ולא לחזור לכתובת פנימית של הפלטפורמה.

זה חשוב לעמודי מוצר, קטגוריות, מאמרים, שיתוף ב-WhatsApp, canonical, Open Graph, sitemap והפניות.

Whitelabel חשוב במיוחד ל-SaaS

בפלטפורמת מסחר רב חנותית, בעל החנות מצפה שהלקוח הסופי יראה את המותג שלו. כתובות ציבוריות שמציגות את שם הפלטפורמה בכל מקום יכולות לפגוע בתחושת העצמאות של החנות.

במקומות שבהם ניתן, כדאי להגיש storefront, metadata ומדיה בצורה שתשמור על המותג של העסק.

דומיין משפיע על תצוגת שיתוף

כאשר לקוח משתף מוצר ב-WhatsApp או ברשת חברתית, כתובת הדומיין היא חלק מה-preview ומהאמון בקישור.

metadata צריך להשתמש ב-origin הציבורי של החנות כדי שלא יוצג domain של מערכת פנימית או tenant אחר.

דומיין משפיע גם על canonical

canonical אומר למנועי חיפוש מהי הכתובת הראשית של העמוד. בחנות עם custom domain, ה-canonical הציבורי צריך להתבסס על הדומיין הנכון של אותה חנות.

זו גם נקודת tenant isolation: אסור שמטא-דאטה של חנות אחת יכיל origin של חנות אחרת.

Sitemap צריך להשתמש באותו origin

אם החנות זמינה ב-custom domain, URLs ב-sitemap צריכים להתאים למבנה הציבורי שנבחר עבורה.

חוסר התאמה בין sitemap, canonical והכתובת שבה המשתמש גולש יוצר בלבול מיותר.

שינוי דומיין דורש redirect מהכתובת הישנה

אם עסק עובר מדומיין אחד לאחר לאחר שכבר צבר תנועה וקישורים, כדאי להפנות URLs ישנים לחדשים בצורה מדויקת ככל האפשר.

הפניה גורפת רק לעמוד הבית פחות טובה כאשר ניתן למפות מוצר ישן למוצר החדש או קטגוריה לקטגוריה.

301 מתאים בדרך כלל למעבר קבוע

כאשר שינוי domain או URL הוא קבוע, redirect קבוע מאפשר לדפדפנים ולמנועי חיפוש להבין שהכתובת עברה.

יש להשתמש בסוג redirect בהתאם למשמעות האמיתית ולא רק משום שקוד אחד נראה מוכר יותר.

אל תחליפו דומיין לעיתים קרובות

דומיין צובר עם הזמן אזכורים, קישורים, זכירות והיסטוריה. שינוי שם בגלל רעיון קטן למיתוג יכול לדרוש redirects, עדכון קמפיינים, אימיילים וחומרי שיווק.

עדיף לבחור שם שאפשר לחיות איתו לאורך זמן.

אם עושים Rebrand - מתכננים את המעבר

Rebrand אמיתי יכול להצדיק domain חדש, אבל צריך להתייחס אליו כפרויקט מעבר. מעדכנים canonical, redirects, sitemap, Search Console, קישורים, פרופילים חברתיים ואימיילים.

הדומיין הישן בדרך כלל צריך להישאר בשליטת העסק ולהמשיך להפנות לחדש.

אל תוותרו מיד על דומיין ישן

גם לאחר מעבר, אנשים יכולים להמשיך להשתמש בקישורים ישנים במשך שנים. אם הדומיין הקודם פג ונרשם על ידי גורם אחר, העסק עלול לאבד תנועה ואפילו ליצור סיכון למותג.

קנו וריאציות חשובות רק כאשר יש לכך הצדקה

אין צורך לרכוש עשרות דומיינים רק כדי למנוע כל אפשרות דומה. אבל מותג משמעותי יכול לשקול וריאציה נפוצה או סיומת מרכזית נוספת אם קיים סיכון ממשי לבלבול.

הדומיינים המשניים צריכים להפנות לראשי ולא להפעיל copies נפרדים של החנות.

Typo domains יכולים להיות שימושיים למותגים מסוימים

אם שם המותג נכתב לעיתים קרובות בצורה שגויה מאוד מסוימת, רכישת הכתובת השגויה והפנייתה יכולה למנוע אובדן של לקוחות.

זה רלוונטי בעיקר כאשר יש כבר נפח משמעותי ולא כדרישה לכל עסק חדש.

אימייל עסקי על הדומיין מחזק את המותג

כתובת כמו support@example.com או contact@example.com מחברת את השירות לאותו domain שהלקוח רואה בחנות.

זה לא אומר שחייבים להפעיל את שירות האימייל אצל אותו ספק שמנהל את האתר. DNS מאפשר לחבר את האתר לשירות אחד ואת האימייל לספק אחר.

MX קובע היכן מתקבל האימייל

רשומות MX מפנות את הדואר הנכנס לספק האימייל. חיבור domain לחנות לא אמור לדרוש מחיקה של MX קיימות אלא אם יש שינוי מכוון בשירות הדואר.

SPF עוזר להגדיר מי רשאי לשלוח בשם הדומיין

SPF הוא record שמאפשר לדומיין להצהיר אילו מערכות מורשות לשלוח אימייל בשמו. הוא אחד המרכיבים שעוזרים לספקי דואר להעריך אם הודעה לגיטימית.

DKIM מוסיף חתימה קריפטוגרפית להודעות

DKIM מאפשר לשירות הדואר לחתום על הודעות כך שהמקבל יכול לבדוק שהן אכן נשלחו על ידי מערכת מורשית ולא שונו בדרך.

לעסק ששולח confirmations, resets או דיוור מהדומיין, SPF ו-DKIM הם חלק חשוב מהגדרת deliverability תקינה.

DMARC מוסיף מדיניות ודיווח

DMARC עובד יחד עם SPF ו-DKIM ומאפשר לבעל הדומיין להגדיר כיצד שרתי דואר צריכים להתייחס להודעות שאינן עוברות אימות ולספק reporting.

את המדיניות כדאי להגדיר בצורה מבוקרת כדי לא לחסום בטעות מערכות לגיטימיות שהעסק עדיין משתמש בהן.

DNS של האתר ו-DNS של האימייל יכולים לחיות יחד

אין צורך לבחור בין אתר ב-Cloudflare לבין אימייל ב-Zoho, Google Workspace או ספק אחר. אותו zone יכול להכיל records שמפנים כל שירות למקום הנכון.

הנקודה החשובה היא לא למחוק records של שירות אחד כאשר מחברים שירות אחר.

שמרו שליטה על חשבון הרשם

Registrar הוא המקום שבו הדומיין רשום מבחינה מסחרית. DNS provider יכול להיות אותו ספק או ספק אחר.

בעל העסק צריך לדעת מי הרשם, באיזה חשבון הדומיין נמצא ומתי הוא מתחדש.

הפעילו אימות דו שלבי

דומיין שנגנב יכול להפיל אתר, אימייל ושירותים נוספים בבת אחת. חשבון registrar ו-DNS הוא חשבון רגיש ולכן כדאי להגן עליו באמצעות MFA ואמצעי שחזור תקינים.

Domain lock מפחית סיכון להעברה לא מורשית

Registrars רבים מאפשרים transfer lock שמקשה על העברת הדומיין ללא פעולה מפורשת. כאשר אין סיבה להעביר אותו, כדאי להשאיר את ההגנה פעילה.

Auto-renew מונע טעות יקרה

דומיין שפג יכול להפסיק אתר ואימייל, ובמקרים קיצוניים אפילו לעבור לבעלות אחרת. הפעלת חידוש אוטומטי עם אמצעי תשלום מעודכן היא הגנה פשוטה.

אל תסמכו רק על כתובת אימייל מהדומיין עצמו לצורך recovery

אם חשבון הדומיין ננעל וה-recovery נשלח לאימייל שתלוי באותו domain, יכולה להיווצר בעיה מעגלית.

כדאי לשמור גם אמצעי שחזור חיצוני ומאובטח בהתאם לאפשרויות הספק.

שינוי Nameservers הוא פעולה רחבה

כאשר משנים nameservers, מעבירים למעשה את ניהול כל ה-DNS לספק אחר. לפני שינוי כזה צריך להעתיק את כל הרשומות החשובות ולא רק את record של האתר.

טעות במעבר יכולה להפיל אימייל, verification ושירותים נוספים גם כאשר האתר עצמו עובד.

לפעמים אין צורך לשנות Nameservers בכלל

פלטפורמה שמחברת custom domain יכולה בדרך כלל לעבוד באמצעות records ב-DNS provider הקיים. אין סיבה לקחת שליטה מלאה על DNS של הלקוח אם הדבר אינו נדרש ארכיטקטונית.

SaaS צריך להשתמש ב-provider abstraction

פלטפורמת ecommerce שמנהלת custom domains לא צריכה לקשור את כל המערכת לספק אחד. Cloudflare יכול להיות provider ראשון, אבל ה-business logic צריך לעבוד דרך abstraction שניתן להחלפה.

כך ניתן להחליף או להוסיף provider בלי לשכתב את כל מודול הדומיינים ואת חוויית המשתמש.

פרטי provider לא צריכים להכביד על בעל החנות

המשתמש צריך לראות enter domain, DNS records, verify ו-status. הוא לא צריך להבין מהו custom hostname object פנימי או מזהה אצל ספק התשתית.

שגיאות domain צריכות להיות שימושיות

במקום הודעה כללית domain verification failed, עדיף להסביר האם חסרה רשומה, קיים value שגוי, SSL עדיין pending או שהדומיין כבר מחובר לחנות אחרת.

מידע ברור מוריד משמעותית את הצורך בתמיכה ידנית.

דומיין לא יכול להשתייך לשתי חנויות במקביל

במערכת multi-tenant צריך להבטיח uniqueness של domain ולמנוע מצב שבו tenant אחד מנסה לחבר כתובת שכבר שייכת לאחר.

האימות חייב להתבצע בצד השרת ולא להסתמך רק על UI.

Tenant isolation חל גם על domain operations

בעל חנות יכול לקרוא, לאמת, לעדכן ולמחוק רק את הדומיינים ששייכים לחנויות שבהן יש לו הרשאה.

מזהה domain או store שנשלח מה-client אינו מספיק. כל פעולה צריכה להיות scoped לחנות שנפתרה באופן מאובטח.

מחיקת חנות צריכה לנקות גם תשתית דומיינים

כאשר tenant נמחק, custom hostnames, mappings ו-resources של provider צריכים להימחק או להתנתק בצורה מסודרת כדי שלא יישארו leftovers.

זה חשוב גם לאבטחה וגם כדי שניתן יהיה להשתמש בדומיין מחדש בעתיד.

ניתוק דומיין לא צריך למחוק את הדומיין עצמו

הפלטפורמה מנהלת את החיבור, לא את הבעלות המסחרית על הדומיין. הסרת custom domain מהחנות צריכה להסיר mapping ו-resources הרלוונטיים, לא לנסות למחוק את registration אצל הרשם.

חיבור דומיין לא חייב להיות תלוי במנוי פעיל

במערכת SaaS אפשר לאפשר לעסק להגדיר ולהכין domain גם אם checkout עדיין נעול בגלל subscription. כך ההכנה הטכנית של החנות אינה חייבת לחכות להפעלת המסלול המסחרי.

כללי subscription יכולים לשלוט ביכולת checkout או במספר הדומיינים בלי לפגוע בתהליך הבעלות והאימות.

מספר הדומיינים יכול להיות חלק ממגבלות התוכנית

אם plans שונים כוללים כמות שונה של custom domains, השרת צריך לאכוף את המגבלה בזמן יצירת domain חדש.

הממשק יכול להסביר את המגבלה, אך enforcement חייב להישאר בצד השרת.

דומיין ראשי ומשניים דורשים כלל ברור

כאשר לחנות יש יותר מדומיין אחד, צריך להחליט מי primary. הדומיינים האחרים יכולים להפנות ל-primary כדי למנוע כפילות ולשמור SEO עקבי.

Locale routing צריך להישאר עקבי תחת הדומיין

אם החנות משתמשת ב-/he ו-/en, חיבור custom domain לא צריך לשנות את מבנה השפות. כתובות canonical, hreflang וה-language switcher צריכים לעבוד תחת אותו domain ציבורי.

אל תיצרו domain נפרד לכל שפה ללא צורך

אפשר לבנות אסטרטגיה עם דומיינים נפרדים לפי מדינה או שפה, אבל היא מוסיפה מורכבות SEO ותפעולית. עבור עסקים רבים prefix שפה תחת domain אחד פשוט יותר.

הבחירה צריכה להגיע מאסטרטגיה עסקית ולא רק משום שאפשר לקנות עוד דומיין.

Search Console צריך להכיר את הדומיין הציבורי

לאחר שהחנות פעילה על domain אמיתי, כדאי להוסיף אותו ל-Google Search Console ולבדוק אינדוקס, sitemap ובעיות סריקה.

בעת מעבר domain צריך לעקוב גם אחר הכתובת הישנה וגם החדשה בתקופת המעבר.

Analytics צריך לעבוד גם אחרי החלפת domain

שינוי כתובת יכול להשפיע על tracking, cookies, referral attribution והגדרות analytics. לפני המעבר כדאי לבדוק שכל מערכות המדידה מכירות את origin החדש.

Webhook URLs יכולים להיות קשורים ל-domain אחר

אין חובה ש-webhooks של payments או integrations יעברו דרך domain החנות. בדרך כלל הם צריכים להצביע ל-API server היציב של הפלטפורמה.

הפרדה בין storefront domain לבין backend integration endpoints מפחיתה תלות בשינויים שהסוחר עושה בדומיין הציבורי.

API URLs אינם צריכים להשתנות עם custom domain

ה-storefront יכול לפעול תחת domain של העסק בזמן שה-client ממשיך לדבר עם API המרכזי של הפלטפורמה. custom domain הוא routing ציבורי של storefront ולא סיבה לחשוף backend שונה לכל tenant.

מדיה היא שיקול Whitelabel נוסף

גם כאשר עמוד המוצר מופיע תחת domain העסק, תמונות יכולות להגיע מ-CDN מרכזי. מבחינה טכנית זה תקין, אבל פלטפורמה שרוצה whitelabel מלא יכולה לשקול proxy או media URLs ממותגים.

יש לבצע זאת בלי לשבור caching, אבטחה, tenant isolation או ניהול media מרכזי.

אין לשכפל קבצי מדיה בשביל domain

דומיין הוא שכבת delivery ו-routing. הוא לא צריך ליצור עותק נפרד של כל תמונה. MediaAsset צריך להישאר מקור המידע המרכזי והכתובת הציבורית יכולה להיפתר מעליו.

בדקו את הדומיין לפני השקת קמפיין

לפני ששולחים אלפי אנשים לכתובת חדשה, כדאי לבדוק אותה במחשב, בטלפון ובכמה רשתות.

• הדומיין נפתח ללא אזהרת SSL
• www והגרסה ללא www מתנהגות לפי ההגדרה
• עמוד הבית נטען
• עמודי מוצר וקטגוריה עובדים
• קישורים פנימיים נשארים על הדומיין הנכון
• שינוי שפה עובד
• checkout עובד
• Open Graph משתמש בדומיין הנכון
• canonical נכון
• sitemap מכיל URLs תקינים
• redirects מהכתובות הישנות עובדים
• אימייל העסק לא נפגע משינויי DNS

בדקו את הדומיין גם מחוץ לרשת שלכם

DNS cache מקומי יכול לגרום לכך שאצל בעל העסק הכל עובד ואצל לקוח עדיין לא. בדיקה ממכשיר סלולרי או רשת אחרת יכולה לתת תמונה טובה יותר לאחר שינוי משמעותי.

אל תפרסמו לפני שה-SSL פעיל

גם אם DNS כבר מצביע למקום הנכון, כדאי לחכות עד שה-certificate מוכן וכל הגרסאות הציבוריות עובדות בלי אזהרה.

איך לבחור דומיין חדש בצורה מסודרת

1. התחילו משם העסק או המותג
2. צרו מספר גרסאות קצרות
3. אמרו כל אפשרות בקול ובדקו אם קל לאיית אותה
4. בדקו שאין משמעות בעייתית בשוק היעד
5. בדקו זמינות של הסיומות המרכזיות
6. בדקו מחיר חידוש
7. בדקו שמות משתמש ברשתות רלוונטיות
8. בצעו בדיקת סימן מסחר כאשר הדבר נדרש
9. בחרו גרסה ראשית אחת
10. רשמו אותה בחשבון שבשליטת העסק
11. הפעילו MFA ו-auto-renew
12. חברו אותה לחנות ורק לאחר verification התחילו לפרסם

טעויות נפוצות בבחירת דומיין

• שם ארוך שקשה לזכור
• איות שאי אפשר להבין משיחה
• דחיסת מילות מפתח רק בשביל SEO
• רכישה לפי מחיר שנה ראשונה בלבד
• השארת הדומיין בחשבון של ספק חיצוני
• שימוש במספרים שלא ברור איך לכתוב
• יותר מדי מקפים
• החלפת domain לעיתים קרובות
• שינוי nameservers בלי להעתיק records של אימייל
• אי הפעלת auto-renew
• אי הפעלת MFA
• השארת www ו-non-www כגרסאות נפרדות
• אי הגדרת redirect לאחר מעבר
• שימוש ב-domain של הפלטפורמה בקישורי SEO ושיתוף לאחר חיבור custom domain

צקליסט לאחר חיבור דומיין לחנות

1. בדקו DNS status
2. בדקו SSL status
3. בחרו primary domain
4. בדקו redirect בין www ו-non-www
5. בדקו HTTPS
6. עברו על עמודי מוצר
7. עברו על קטגוריות ומאמרים
8. בדקו canonical
9. בדקו hreflang אם יש כמה שפות
10. בדקו sitemap
11. בדקו robots
12. שלחו קישור ב-WhatsApp ובדקו preview
13. בדקו favicon ולוגו
14. בדקו checkout
15. בדקו אימיילים
16. הוסיפו Search Console
17. בדקו analytics
18. בצעו smoke test מרשת נוספת

לסיכום

דומיין הוא חלק מהמותג, מהאמון ומהתשתית של חנות אונליין. הוא צריך להיות קל לזכור, קל לאיות, בבעלות העסק ויציב לאורך זמן.

הבחירה עצמה היא רק השלב הראשון. לאחר מכן צריך לחבר DNS בצורה נכונה, להפעיל SSL, לבחור כתובת ראשית, להגדיר redirects ולוודא ש-canonical, sitemap, שיתופים ואימיילים משתמשים בתצורה הנכונה.

כאשר התהליך בנוי היטב, בעל העסק לא צריך להיות מומחה DNS. הוא מכניס את הדומיין, מקבל את הרשומות הנדרשות, מאמת את החיבור וממשיך לעבוד. המורכבות הטכנית נשארת מאחורי הקלעים, והלקוח רואה חנות מקצועית תחת המותג שהוא מכיר.