وقتی یک مهاجرت CMS تعریف میشود، بیشتر بحثها درباره جنبه فنی است: انتخاب پلتفرم، فرمت خروجی داده، فیلدهای سفارشی، ریدایرکتها، ساختار API، کارایی. اینها نگرانیهای واقعی هستند. اما معمولاً دلیل دیر تحویل شدن، افت ترافیک، یا ناگزیر شدن به بازنگری شش ماه بعد از راهاندازی نیستند.
چالشهای سختتر معمولاً سازمانی هستند: چه کسی مالک محتوا است، چه محتوایی مهاجرت میشود در مقابل آنچه آرشیو میشود، جریانهای کاری تحریریه چطور تغییر میکنند، ذینفعان چه زمانی باید درگیر شوند، و «آماده برای راهاندازی» واقعاً یعنی چه.
مشکل فهرست محتوا
بیشتر سازمانها دستکم میگیرند که چقدر محتوا دارند — و چه مقدار از آن در وضعیت بدی است. قبل از شروع هر مهاجرتی، یک فهرست محتوا باید این سوالها را جواب بدهد:
- چه محتوایی وجود دارد و کجاست؟
- چه چیزی فعال است، چه چیزی منسوخ شده، و چه چیزی باید آرشیو شود؟
- کدام URLها ترافیک یا بکلینک معناداری دارند که باید حفظ شوند؟
- چه متادیتایی غایب، ناهماهنگ، یا مخصوص پلتفرم قدیمی است؟
این کار خستهکننده است. همینجاست که بیشتر شگفتیهای مهاجرت از آن میآیند. کشف کردن در میانه مهاجرت که یک بخش از سایت صدها صفحه قدیمی با متادیتای خراب دارد — یا اصلاً متادیتا ندارد — کار برنامهریزینشدهای ایجاد میکند که روی زمانبندی و کیفیت تأثیر میگذارد.
فهرست محتوایی که قبل از شروع مهاجرت فنی انجام میشود سربار نیست. پایهای است که بقیه پروژه روی آن میایستد.
حفظ سئو و ساختار URL بهعنوان مسئولیت مشترک
حفاظت از سئو در طول مهاجرت فقط یک وظیفه توسعهدهنده نیست. به ورودی تیم تحریریه نیاز دارد (کدام URLها مهماند و چرا)، تیم آنالیتیکس (چه الگوهای ترافیکی وجود دارد)، و هر کسی که استراتژی جستوجوی سایت را در اختیار دارد.
رایجترین دلایل افت ترافیک پس از مهاجرت اینها هستند:
- URLهایی که تغییر کردند بدون اینکه ریدایرکت درستی در جا گذاشته شده باشد.
- تگهای کانونیکال که در دوره انتقال به دامنه یا نسخه اشتباه اشاره میکردند.
- محتوایی که مهاجرت شد اما پیدا کردنش سختتر شده چون تاکسونومی تغییر کرده.
- صفحاتی که به اشتباه از سایتمپ جدید حذف شدند.
هیچکدام از اینها خرابی صرفاً فنی نیستند. وقتی هماهنگی بین تیم فنی و تحریریه از بین میرود — یا وقتی هیچ چکلیست مشترکی برای تأیید هر مورد قبل از راهاندازی وجود ندارد — اتفاق میافتند.
تغییر جریانهای کاری تحریریه به برنامه نیاز دارد
یک CMS جدید اغلب نحوه ایجاد، بازبینی و انتشار محتوا را تغییر میدهد. اگر این تغییر برنامهریزی نشود، بعد از راهاندازی به یک مشکل آموزش و پذیرش تبدیل میشود.
سوالهایی که ارزش دارد قبل از تکمیل مهاجرت پاسخ داده شوند:
- در سیستم جدید چه کسی چه کاری میتواند انجام دهد؟
- جریان کاری انتشار چیست — پیشنویس، بازبینی، تایید، زمانبندی؟
- کدام قالبها یا کامپوننتها جایگزین فرمتهای موجود میشوند؟
- چه محتوایی را خود ویراستاران میتوانند مدیریت کنند و چه چیزی به توسعهدهنده نیاز دارد؟
این سوالها افرادی را درگیر میکنند که توسعهدهنده نیستند. پاسخ دادن به آنها زودهنگام، مستند کردن پاسخها، و اجرای آموزش قبل از راهاندازی تفاوت بین یک تحویل سالم و یک هفته اول آشفته است.
همراستایی ذینفعان و آمادهسازی برای راهاندازی
مهاجرتها اغلب در مرحله نهایی متوقف میشوند چون «آماده برای راهاندازی» برای افراد مختلف معنای متفاوتی دارد. برخی ذینفعان میخواهند قبل از لایو شدن کاملاً برابری ویژگیها با سیستم قدیمی محقق شود. برخی دیگر میخواهند سریع حرکت کنند و بهبود دهند. بدون یک تعریف مشترک از معیارهای راهاندازی، پروژه میتواند وارد یک چرخه بازبینی بیپایان شود.
یک سند آمادهسازی برای راهاندازی — حتی یک چکلیست ساده — که معیارهای توافقشده را ثبت میکند این شکاف را میبندد. ممکن است شامل این موارد باشد:
- تمام محتوای اولویتدار مهاجرت شده و بازبینی شده.
- ریدایرکتها برای URLهای پرترافیک و مهم از نظر سئو تأیید شده.
- جریانهای کاری اصلی تحریریه از ابتدا تا انتها تست شده.
- آنالیتیکس و ردیابی تأیید شده.
- تایید هر مسئول تیم دریافت شده.
این کار مدیریت پروژه است، نه کار توسعه. اما بدون آن، کار توسعه به یک راهاندازی موفق تبدیل نمیشود.
چه چیزی مهاجرتها را موفق میکند
مهاجرتهایی که روان پیش میروند چند ویژگی مشترک دارند: یک مالک محتوای واضح که تصمیمها را پیش میبرد، یک فهرست محتوای زودهنگام و صادقانه، یک چکلیست مشترک برای معیارهای راهاندازی، و چکهای منظم همراستایی ذینفعان در طول پروژه.
اجرای فنی مهم است. اما لایه هماهنگی دور آن — چه کسی مسئول چیست، چطور تصمیمها گرفته میشوند، و تعریف «تمامشدن» چیست — همان چیزی است که مهاجرتی را که سالم راهاندازی میشود از مهاجرتی که ماهها بعد از تکمیل کار فنی هنوز ادامه دارد جدا میکند.