בכל שבוע מישהו מגיע ורוצה להעביר אתר אמיתי — כזה עם תנועה, קישורים נכנסים, כמה שנים של אמון שנבנה מול גוגל. לא רעיון טרי, לא אב-טיפוס. עסק קיים עם משהו להפסיד. זו עבודה שונה מהתחלה מפרומפט ריק, ורוב הכאב שראיתי נובע מהתייחסות אליה כאילו זו אותה עבודה בכל זאת.
יש שלוש דרכים שבהן זה משתבש בתדירות מספקת כדי שאוכל לחזות את פניית התמיכה עוד לפני שקראתי מעבר לכותרת. הדרך הנכונה אינה מתוחכמת. היא פשוט הדבר שאליו מגיעים ברגע שמפסיקים לעשות את שלוש הטעויות האלה.
טעות ראשונה: לשפוך את התוכן הישן פנימה ולקוות שהמבנה יסתדר מעצמו
האינסטינקט הגיוני. יש לכם אתר, יש בו מילים, אז אתם מדביקים את המילים בצ'אט ומבקשים מהבנאי "לשפר את זה". מה שיוצא בדרך כלל הוא אתר שנראה חדש ונקרא ישן — אותם פסקאות שירות רצות ומתמשכות, אותן שלוש כותרות שעושות את העבודה של חמש עשרה, עכשיו עטופות בתבנית יפה יותר. הבנאי עשה מה שביקשתם. ביקשתם ממנו לעצב מחדש, לא לחשוב מחדש.
ההריסות מופיעות בערך שישה שבועות מאוחר יותר, כשהדירוגים של האתר החדש יושבים בדיוק במקום שבו היו בישן, או קצת נמוך יותר. שום דבר לא השתפר כי שום דבר במבנה המידע בפועל לא השתנה — אותו עמוד שטוח לשירות שהיה צריך להיות שלושה עמודים, אותו תוכן שאלות נפוצות חסר שאתר של מתחרה מדורג עליו כבר שנה. שכבת צבע חדשה על בית עם מספר חדרים שגוי עדיין נשאר בית עם מספר חדרים שגוי.
היה לי לקוח עם עמוד "שירותים" בן 4,000 מילים שכיסה אחת עשרה הצעות שונות. היא רצתה שהוא יועבר כמות שהוא כי "זה תמיד עבד". זה לא עבד — הוא לא דורג לשום דבר ספציפי כי הוא עסק בהכול בבת אחת. העברה נאמנה שלו הייתה רק יוצרת גרסה נחמדה יותר של אותו עמוד שלא מדרג.
מה שבאמת עובד כאן הוא להתייחס להעברה כאל ביקורת (אודיט) לפני שהיא בנייה. הזינו את התוכן הישן, אבל בקשו קודם מלאי תוכן: אילו עמודים קיימים, על מה כל אחד באמת מנסה להתמקד בדירוג, איפה שני נושאים דחוסים בכתובת אחת ואיפה נושא אחד דליל על פני חמש כתובות. המלאי הזה הופך לתוכנית. האתר הישן הוא מקור, לא תבנית.
טעות שנייה: לשכוח שהכתובות (URL) הן הדבר שגוגל באמת סומכת עליו
זו הטעות היקרה. העברת אתר שמשנה את מבנה הכתובות בלי למפות נתיבים ישנים לחדשים — גם כשהתוכן החדש טוב יותר באמת — זורקת לפח שנים של אות מצטבר. קישורים נכנסים מצביעים אל 404. גוגל צריכה לזחול מחדש ולזכות מחדש באמון בעמודים שכבר סמכה עליהם בכתובת אחרת. תנועה ישירה מסימניות ומחתימות אימייל ישנות מגיעה למבוי סתום.
ראיתי אנשים שמים לב לכך רק אחרי ההשקה, כשלוח הבקרה של האנליטיקס מציג צוק במקום עלייה. עד אז התיקון הוא הוספת הפניות בדיעבד, מה שמשחזר חלק מההפסד אבל לא את כולו — הפער בין "הכתובת עברה" ל-"מישהו שם לב ותיקן" נמדד בשבועות של הון שלא חוזר.
| הגישה הישנה | מה נשבר | מה לעשות במקום זה |
|---|---|---|
| לתת לבנאי ליצור כל מבנה כתובות שמתאים לעיצוב החדש | כל קישור נכנס וסימניה מצביעים עכשיו אל 404 | לייצא קודם את מפת האתר הישנה, למפות כל כתובת קיימת למקבילה החדשה שלה לפני תחילת הבנייה |
| להפנות רק את דף הבית, ולתת לעמודים הפנימיים להיכשל ב-404 | עמודים עמוקים נושאים הון קישורים משלהם — אובדנם בנפרד מצטבר | לבצע 301 לכל כתובת ישנה משמעותית, גם לכאלה שמתמזגות לעמוד רחב יותר |
| להוסיף הפניות "אחר כך, ברגע שהאתר עולה לאוויר" | זחלנים ומשתמשים לוחצים נתקלים במבואות סתומים בדיוק בחלון הזמן שבו התנועה הכי תנודתית | ההפניות עולות לאוויר באותו רגע שבו האתר החדש עולה, לא אחר כך |
שום דבר מזה לא אקזוטי. זה גיליון אלקטרוני עם שתי עמודות, שנעשה לפני שמישהו נוגע בבנאי. זה פשוט השלב שאנשים מדלגים עליו כי הוא משעמם והבנייה עצמה היא החלק הכיף.
טעות שלישית: מעבר חד-פעמי (big-bang) בלי דרך חזרה
אופן הכשל השלישי לא קשור בכלל לתוכן או לכתובות — הוא קשור לאופן שבו המעבר בפועל קורה. מישהו בונה את האתר החדש, אוהב מה שהוא רואה בתצוגה מקדימה, ומכוון את הדומיין אליו אותו אחר צהריים. בלי תקופת בדיקה, בלי השוואה זה-לצד-זה תחת תנועה אמיתית, בלי תוכנית למה קורה אם משהו שבור שהתצוגה המקדימה לא תפסה — טופס יצירת קשר שנכשל בשקט, תהליך תשלום שעובד בבדיקות אבל נחנק תחת נפח תשלומים אמיתי, עמוד שמוצג יפה בדסקטופ ונשבר בדיוק בטלפון שחצי מהלקוחות שלכם משתמשים בו.
ההריסות כאן הן מהסוג הרועש ביותר כי הן מיידיות. תיבות התמיכה מתמלאות. מישהו מרענן את האנליטיקס כל עשר דקות וצופה בגרף נע בכיוון הלא נכון, וחזרה לאחור פירושה כיוון מחדש של ה-DNS, מה שבעצמו לוקח זמן להתפשט, מה שאומר שהחוויה הרעה נמשכת גם אחרי שהחלטתם לבטל את השינוי.
התיקון לא מרשים: להנמיך את ה-TTL של ה-DNS יום-יומיים לפני המעבר כדי שכל נסיגה תופץ מהר אם תצטרכו, להריץ את האתר החדש בסאבדומיין תצוגה מקדימה או סטייג'ינג קודם ובאמת להשתמש בו כמו לקוח, ולהשאיר את האחסון של האתר הישן חי ולא נגוע במשך שבועיים לפחות אחרי המעבר במקום לפרק אותו ברגע שהחדש עולה. החלק האחרון עולה כמה דולרים של אחסון כביטוח אמיתי. אנשים מדלגים על זה כי ביטול התוכנית הישנה מרגיש כמו סגירת מעגל, וסגירת מעגלים מרגישה כמו התקדמות.
איך נראית הדרך הנכונה בפועל
בסיכומו של דבר, כל זה לא עבודה רבה יותר מהגרסאות השגויות — זו אותה כמות עבודה בסדר שונה. בצעו ביקורת לפני שבונים מחדש. מפו כתובות URL לפני ההשקה. הריצו שלב סטייג'ינג לפני המעבר, ושמרו על דרך חזרה למשך כמה שבועות אחרי שהוא בוצע. האתר שיוצא בסוף לא רק נראה חדש יותר. הוא שומר על כל מה שהאתר הישן כבר הרוויח, וזו בדיוק הייתה כל המטרה של הגירה במקום התחלה מאפס.
