هر هفته کسی پیدا میشود که میخواهد یک سایت واقعی — با ترافیک، بکلینک، و چند سال اعتماد گوگل پشتش — را به یک سازندهی هوشمصنوعی منتقل کند. نه یک ایدهی تازه، نه یک نمونهی اولیه. یک کسبوکار موجود که چیزی برای از دست دادن دارد. این کار متفاوتی نسبت به شروع از یک پرامپت خالی است، و بیشتر دردسری که دیدهام از این ناشی میشود که با آن مثل همان کار برخورد شده.
سه راه وجود دارد که این کار آنقدر زیاد اشتباه میرود که میتوانم تیکت پشتیبانی را قبل از خواندن ادامهی موضوع پیشبینی کنم. راه درست چیز پیچیدهای نیست. فقط همان چیزی است که وقتی این سه اشتباه را کنار بگذاری، بهش میرسی.
اشتباه اول: تخلیهی محتوای قدیمی و امید به اینکه ساختار خودش سروسامان بگیرد
این غریزه منطقی است. یک سایت داری، محتوا دارد، پس متن را در چت میچسبانی و از سازنده میخواهی «بهترش کند». نتیجه معمولاً سایتی است که تازه به نظر میرسد اما قدیمی خوانده میشود — همان پاراگرافهای طولانی خدمات، همان سه سرتیتر که کار پانزدهتا را انجام میدهند، حالا در قالبی زیباتر. سازنده همان کاری را کرد که خواستی. تو از او خواستی بازچینی کند، نه بازاندیشی.
خرابی حدود شش هفته بعد نمایان میشود، وقتی رتبههای سایت جدید دقیقاً همانجایی میایستند که سایت قدیمی بود، یا کمی پایینتر. هیچ چیزی بهتر نشده چون هیچ چیزی دربارهی معماری اطلاعاتِ واقعی تغییر نکرده — همان صفحهی تخت برای خدماتی که باید سه صفحه میبود، همان محتوای پرسشهای متداول ازقلمافتاده که سایت یک رقیب یک سال است روی آن رتبه گرفته. یک لایه رنگ تازه روی خانهای با تعداد اتاق اشتباه، هنوز هم خانهای با تعداد اتاق اشتباه است.
مشتریای داشتم با صفحهی «خدمات» چهارهزار کلمهای که یازده خدمت متمایز را پوشش میداد. او میخواست همانطور که هست منتقل شود چون «همیشه جواب داده». جواب نداده بود — برای هیچ چیز خاصی رتبه نمیگرفت چون دربارهی همهچیز با هم بود. انتقال وفادارانهی آن فقط نسخهی زیباتری از همان صفحهی بیرتبه میساخت.
چیزی که واقعاً اینجا جواب میدهد این است که انتقال را قبل از ساخت، بهعنوان یک ممیزی در نظر بگیری. محتوای قدیمی را وارد کن، اما اول یک فهرست محتوا بخواه: چه صفحاتی وجود دارند، هرکدام واقعاً برای چه چیزی تلاش میکنند رتبه بگیرند، کجا دو موضوع در یک URL فشرده شدهاند و کجا یک موضوع در پنج صفحه رقیق شده. آن فهرست تبدیل به برنامه میشود. سایت قدیمی یک منبع است، نه یک الگو.
اشتباه دوم: فراموش کردن اینکه URLها همان چیزی هستند که گوگل واقعاً به آنها اعتماد دارد
این همان اشتباه هزینهبر است. انتقال سایتی که ساختار URL را بدون نگاشت مسیرهای قدیمی به جدید تغییر میدهد — حتی وقتی محتوای جدید واقعاً بهتر است — سالها سیگنال انباشته را دور میریزد. بکلینکها به یک صفحهی ۴۰۴ اشاره میکنند. گوگل باید صفحاتی را که قبلاً تحت آدرسی دیگر به آنها اعتماد داشت، دوباره خزش و دوباره اعتماد کند. ترافیک مستقیم از بوکمارکها و امضاهای ایمیل قدیمی به بنبست میرسد.
دیدهام که مردم این را فقط بعد از راهاندازی متوجه میشوند، وقتی داشبورد آنالیتیکس بهجای یک جهش، یک پرتگاه نشان میدهد. تا آن موقع، راهحل اضافه کردن ریدایرکتها بعد از واقعه است، که بخشی از ضرر را جبران میکند نه همهاش — فاصلهی بین «URL جابهجا شد» و «کسی متوجه شد و درستش کرد» با هفتهها ارزش ازدسترفتهای اندازهگیری میشود که برنمیگردد.
| رویکرد قدیمی | چه چیزی خراب میشود | چه کاری باید انجام داد |
|---|---|---|
| بگذار سازنده هر ساختار URLی که با طراحی جدید همخوانی دارد تولید کند | هر بکلینک ورودی و بوکمارک حالا به یک ۴۰۴ اشاره میکند | ابتدا نقشهی سایت قدیمی را استخراج کن، هر URL موجود را قبل از شروع ساخت به معادل جدیدش نگاشت کن |
| فقط صفحهی اصلی را ریدایرکت کن و بگذار صفحات داخلی ۴۰۴ بدهند | صفحات عمیق ارزش لینک مختص به خودشان را دارند — از دست دادن تکتک آنها روی هم انباشته میشود | هر URL قدیمی معنادار را ۳۰۱ ریدایرکت کن، حتی آنهایی که در یک صفحهی گستردهتر ادغام میشوند |
| ریدایرکتها را «بعداً، وقتی سایت آنلاین شد» اضافه کن | خزندهها و کاربران در همان بازهای که ترافیک بیثباتترین حالتش را دارد، به بنبست میخورند | ریدایرکتها را همان لحظهای فعال کن که سایت جدید آنلاین میشود، نه بعدش |
هیچکدام از اینها عجیب نیست. یک صفحهگسترده با دو ستون است که قبل از دستزدن هرکسی به سازنده تهیه شده. این فقط مرحلهای است که مردم رد میشوند چون خستهکننده است و خود ساختوساز بخش سرگرمکنندهی کار است.
اشتباه سوم: انتقال یکباره بدون راه بازگشت
سومین حالت شکست اصلاً دربارهی محتوا یا URL نیست — دربارهی نحوهی واقعی انجام تعویض است. کسی سایت جدید را میسازد، از چیزی که در پیشنمایش میبیند خوشش میآید، و همان بعدازظهر دامنه را به آن سمت هدایت میکند. بدون دورهی آزمایشی، بدون مقایسهی همزمان تحت ترافیک واقعی، بدون برنامهای برای اتفاقی که اگر چیزی خراب باشد که پیشنمایش نگرفته — فرمی که بیصدا کار نمیکند، فرآیند پرداختی که در تست کار میکند اما زیر حجم واقعی پرداخت خفه میشود، صفحهای که روی دسکتاپ خوب نمایش داده میشود اما دقیقاً روی همان گوشیای که نیمی از مشتریانت استفاده میکنند خراب میشود.
خرابی اینجا بلندترین نوع است چون فوری است. صندوقهای پشتیبانی پر میشوند. یک نفر هر ده دقیقه آنالیتیکس را رفرش میکند و میبیند نموداری در جهت اشتباه حرکت میکند، و بازگشت به عقب یعنی دوباره تنظیم DNS، که خودش زمان میبرد تا منتشر شود، که یعنی تجربهی بد حتی بعد از تصمیم به معکوس کردن، ادامه پیدا میکند.
راهحل بیجلوه است: یکی دو روز قبل از انتقال، TTL دیاناس را کاهش بده تا هر بازگشتی سریع منتشر شود اگر لازم شد، سایت جدید را ابتدا روی یک زیردامنهی پیشنمایش یا استیجینگ اجرا کن و واقعاً همانطور که یک مشتری استفاده میکند از آن استفاده کن، و هاست سایت قدیمی را دستنخورده و فعال نگه دار برای حداقل چند هفته بعد از انتقال، بهجای اینکه همان لحظه که سایت جدید بالا آمد آن را از بین ببری. آن بخش آخر فقط چند دلار هزینهی هاست میگیرد در ازای یک بیمهی واقعی. مردم آن را رد میکنند چون لغو پلن قدیمی حس بستن یک حلقه را میدهد، و بستن حلقهها حس پیشرفت میدهد.
شکل واقعی راه درست چیست
روی هم رفته، هیچکدام از اینها کار بیشتری نسبت به نسخههای اشتباه نیست — همان مقدار کار است فقط با ترتیبی متفاوت. قبل از بازسازی ممیزی کن. قبل از راهاندازی، URLها را نگاشت کن. قبل از تعویض، مرحلهبندی کن، و چند هفته بعدش راه بازگشت را نگه دار. سایتی که در پایان بیرون میآید فقط تازهتر به نظر نمیرسد. هرچه سایت قدیمی قبلاً کسب کرده بود را حفظ میکند، که کل نکتهی انتقال بهجای شروع از صفر همین بود.
