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

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

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

לפני ההגדרה: מגדירים את מטרת ההפניה

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

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

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

301, 302 ו-308: בחירה לפי כוונה, לא לפי הרגל

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

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

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

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

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

הפניה ברמת הדומיין היא רק השכבה הראשונה. הפניה חכמה צריכה לשאול מה עושים עם הנתיב שאחרי שם הדומיין. אם `old-domain.co.il/services` עובר ל-`new-domain.co.il/services`, שמירת הנתיב היא בדרך כלל ההתנהגות הרצויה. כך גם לגבי קישורים עמוקים לעמודי מוצר, מאמרים, מסמכים או אזורי לקוחות.

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

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

אל תאבדו פרמטרים בדרך

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

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

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

DNS אינו ההפניה עצמה

רשומת DNS מפנה שם דומיין לשרת או לשירות. היא אינה מחליפה תשובת HTTP של הפניה. זו הבחנה בסיסית, אך היא מקור קבוע לטעויות: שינוי רשומת `A`, `CNAME` או `ALIAS` לא אומר שהדפדפן יקבל 301 או 302.

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

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

HTTPS, דומיין שורש ו-www: מטפלים בכל הכניסות

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

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

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

בדיקות שחייבות לקרות אחרי הפרסום

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

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

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

שליטה בקנה מידה: ההפניה היא נכס מנוהל

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

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

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

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