דילוג לתוכן
בלוג

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

מערכת Tekravel

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

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

איפה הדומיין שלכם באמת גר

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

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

דומיין ראשי או תת-דומיין: החליטו לפני שנוגעים במשהו

הדומיין הראשי (apex, או "דומיין עירום") הוא yourbrand.co.il בלי שום דבר לפניו. תת-דומיין הוא כל כתובת עם קידומת: www.yourbrand.co.il, book.yourbrand.co.il, travel.yourbrand.co.il. הפלטפורמה מקבלת את שניהם, אבל הבחירה קובעת איזו רשומה תוסיפו.

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

ראשי (yourbrand.co.il)תת-דומיין (book.yourbrand.co.il)
הרשומה שמוסיפיםרשומת A לכתובת IPCNAME לשם מארח של הפלטפורמה
מה הלקוח מקלידהכתובת הקצרה ביותר האפשריתמילה אחת יותר, שחשובה פחות כשהלקוח מגיע דרך קישור
האתר הקיים שלכםחייב לעבור מהדומיין הראשי, אחרת אתר ההזמנות מחליף אותונשאר בדיוק איפה שהוא
הדואר של העסקלא מושפע, כל עוד לא נוגעים ברשומות MXלא מושפע
מתאים לסוכנות שהאתר שלה הוא אתר ההזמנותסוכנות עם אתר תדמית, בלוג או CMS שהיא רוצה לשמור

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

הרשומות שמוסיפים ומה כל אחת עושה

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

  • CNAME, לתת-דומיין. שם: הקידומת שבחרתם, למשל book. ערך: שם המארח של הפלטפורמה ששלב ה-DNS נותן. המשמעות: "השם הזה הוא כינוי של השם ההוא", כך שאם השרתים של הפלטפורמה עוברים, הרשומה שלכם ממשיכה לעבוד בלי שתיגעו בה.
  • רשומת A, לדומיין ראשי. שם: @, הסימן שרוב ממשקי ה-DNS משתמשים בו לדומיין עצמו. ערך: כתובת ה-IP ששלב ה-DNS נותן. המשמעות: "השם הזה גר בכתובת הזאת".
  • TXT, לפעמים. סביבות אחסון מסוימות מבקשות גם רשומת אימות: מחרוזת אקראית ארוכה תחת שם ששלב ה-DNS מציין. היא לא עושה דבר עבור המבקרים. היא מוכיחה שמי ששולט בדומיין הסכים לחיבור. אם השלב מציג אותה, הוסיפו; אם לא, שום דבר לא חסר.

שתי טעויות מסבירות את רוב הניסיונות שנכשלים. הראשונה היא להקליד את הדומיין המלא בשדה השם. ממשקים רבים מוסיפים את הדומיין אוטומטית, כך ש-book.yourbrand.co.il שהוקלד שם הופך ל-book.yourbrand.co.il.yourbrand.co.il, שלא מוביל לשום מקום. הקלידו רק את הקידומת. השנייה היא להשאיר רשומה ישנה במקומה. אם ל-book יש כבר רשומת A מפרויקט קודם, CNAME לא יכול לשבת לידה, ויש ממשקים שמשאירים את הישנה בשקט. מחקו קודם את הרשומה הישנה של השם המדויק הזה.

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

למה המנעול מגיע אחרון

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

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

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

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

כמה עולה טעות

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

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

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

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

שמרו את דומיין הפלטפורמה — הוא רשת הביטחון שלכם

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

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

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

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

  1. בררו מי מארח את ה-DNS שלכם. שרתי השמות של הדומיין יגידו לכם.
  2. בחרו דומיין ראשי או תת-דומיין. אם יש אתר שאתם רוצים לשמור, בחרו תת-דומיין.
  3. לפני כל שינוי, תעדו את כל הרשומות הקיימות, במיוחד MX. צילום מסך מספיק.
  4. מחקו כל רשומה ישנה על השם המדויק שבו תשתמשו.
  5. הוסיפו את הרשומה משלב ה-DNS: CNAME לתת-דומיין, A לדומיין ראשי, ועוד TXT אם השלב מציג אותה. בשדה השם הקלידו רק את הקידומת.
  6. העבירו כל פרוקסי על הרשומה הזאת למצב DNS בלבד.
  7. חכו שהרשומה תיפתר באופן ציבורי. אל תמשיכו לערוך אותה.
  8. ודאו שהמנעול מופיע, בצעו הזמנת ניסיון בכתובת החדשה, ורק אז עדכנו את הלקוחות.

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

מערכת Tekravel

דסק טכנולוגיות תיירות

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