نحوه کامل کردن خاموش شدن وب سایت با انتقال تقسیم

اخیراً یک برند بزرگ جهانی از من خواسته است که از پروژه خاموش کردن وب سایت پشتیبانی کنم. این شرکت به اندازه کافی برای حفظ خود و کسب سود درآمد نداشت. همین برند جهانی همچنین مالک چندین شرکت مشابه دیگر در این حوزه است.

خاموش کردن یک وب سایت آسان است، اما زمانی که باید این کار را همراه با تغییر مسیر انجام دهید، چه کاری و چگونه انجام می دهید؟

یکی از ملزومات این بود که خاموش شدن بدون مشکل انجام شود و نیمی از ترافیک به یک وب سایت و نیمی دیگر به وب سایت دیگر هدایت شود. عامل تعیین کننده نوع محصول بود.

چرا به آن ‘split migration’ می گویند؟

مهاجرت وب سایت یک فرآیند دقیق و رویه ای است که اغلب شامل تغییر دامنه و URL ها، طراحی مجدد یا تغییر پلت فرم است. در حالی که \ حتی در یک سایت کوچک خسته کننده است، مشکلاتی که می توانید با آنها مواجه شوید تنها با هر صفحه اضافی یک سایت تشدید می شود.

اکنون، سایتی با هزاران صفحه یا محصول را تصور کنید که باید آنها را در مهاجرت قرار دهید. به پیچیدگی انتقال بخش هایی از یک سایت بین دو سایت دیگر اضافه کنید.

وقتی باید هزاران صفحه و محصول را به دو وب سایت متفاوت و موجود منتقل کنید، چگونه با هزاران صفحه و محصول برخورد می کنید؟

قبل از این مرحله، من هرگز یک مهاجرت تقسیمی انجام ندادم، اما یک ایده کلی در مورد اینکه از کجا شروع کنم و چگونه فرآیند را شروع کنم، داشتم.

متأسفانه، مهاجرت چیزی بیش از یک تغییر مسیر ساده است. هر مهاجرتی با مشکلاتی همراه است، اما این مورد خاص کمی آسان‌تر بود، زیرا فقط شامل تغییر مسیرهای URL از مبدا به صفحه(های مقصد) بود.

با این حال، این فرآیند برای یک مهاجرت معمولی یا پلتفرم جدید که شامل موارد زیر است، دشوارتر خواهد بود:

• فراداده
• محتوا
• سرفصل ها
• خطاهای 404
• تغییر مسیرهای موجود
• تصاویر
• و غیره.

از نظر تضمین کیفیت (QA)، یک تغییر مسیر URL اصلی برای آزمایش و تأیید اینکه همه چیز به درستی کار می کند آسان تر است. با این حال، ما هنوز مراحل متعددی را پشت سر گذاشتیم تا فرآیند به آرامی پیش برود، که با “کشف” شروع شد.

مرحله کشف

می دانستم که بزرگترین چالش من شناسایی صفحات موجود در هر سه وب سایت است. برای حفظ حریم خصوصی، مالکیت معنوی و دیگر دلایل قانونی، اجازه دهید آنها را Source، Destination1 و Destination2 بنامیم.

من با خزیدن Screaming Frog شروع کردم که به وب‌سایت منبع می‌رفت و تمام صفحات قابل فهرست‌بندی را شناسایی می‌کرد. و برای فرآیند تصمیم‌گیری آسان‌تر، مجبور شدم داده‌های Google Analytics و کنسول جستجوی Google را با استفاده از APIها جمع‌آوری کنم.

اما من هنوز اطلاعات دیگری را از دست داده بودم. من به Semrush API دسترسی نداشتم، بنابراین مجبور شدم داده های بک لینک را جداگانه بکشم. هنگامی که لیست URL هایی را که باید با آنها کار کنید تهیه کردید، مطمئن شوید که داده های بک لینک را نیز استخراج می کنید.

می توانید این را به Ahrefs یا منبع دیگری که ترجیح می دهید تغییر دهید. نکته اینجاست که بدانید یک URL از نظر بک لینک چقدر اهمیت دارد.

---

---

مرحله راه اندازی

اکنون که تمام URL های خود را از سایت منبعی که باید با آن کار می کردم جمع آوری کردم، به چند چیز نیاز داشتم تا روند را راحت تر کنم:

• لیست را پاک کنید تا پارامترهای URL یا موارد تکراری دیگر حذف شوند.
• صاحبان صفحه را شناسایی کنید (به کدام سایت باید برود – Destination1 یا Destination2).
• اولویت صفحه چیست؟ (آیا ترافیک مستقیم دارد؟ آیا در گوگل رتبه دارد؟ بک لینک دارد؟)
• کد وضعیت صفحه چیست؟ (این 200 است یا 301 یا 404؟)

من داده های ScreamingFrog و داده های Semrush خود را در برگه های جداگانه قرار دادم و یک فایل Google Sheets ایجاد کردم:

در ابتدا، من فایل را با همه طرف ها و صاحبان درگیر به اشتراک گذاشتم، این به آنها اجازه داد تا URL هایی را که متعلق به مقصد خاص هستند انتخاب کنند. به یاد داشته باشید که هر URL ممکن است همتای مالک خود را در هر یک از آن وب سایت ها داشته باشد.

به عنوان مثال، یک محصول خاص در وب سایت منبع و مقصد وجود دارد، بنابراین تغییر مسیر نهایی باید به URL مقصد و همان صفحه باشد.

شما همچنین می توانید انتخاب کنید که پارامترها را منتقل کنید. بنابراین مطمئن شوید که مقصد به درستی پر شده است.

در وظیفه‌ام، من با 18000 URL کار می‌کردم و پس از فیلتر کردن و حذف آن‌هایی که مهم نبودند، به 11000 رسیدم.

آزمایش کردن

در بیشتر موارد، شما باید این را روی یک سرور موقت آزمایش کنید. برای مثال، ممکن است تنظیماتی از URLهای منبع واقعی شما وجود داشته باشد یا نباشد dev.source.com بجای source.com.

شما به راحتی می توانید URL های منبع خود را به طور موقت جایگزین کنید، یا از یک فایل تکراری استفاده کنید.

هنگام آزمایش، مطمئن شوید که از همان پیکربندی استفاده می‌کنید که در زمان کشف استفاده کردید.

به روز رسانی صادرات ScreamingFrog در ورق SF-Internal ALL به طور خودکار داده ها را تنظیم می کند ورق URL و آنهایی را که URL مقصد ناموفق دارند به شما نشان می دهد.

اما چه اشتباهی رخ داد؟

هر مهاجرت یک تجربه یادگیری است. اگر تا به حال یک انتقال انجام داده اید، می دانید که یک اشتباه می تواند منجر به خطاهای 404، بارگیری نشدن تصاویر یا مشکلات دیگر شود. خوشبختانه، بزرگ‌ترین مشکلی که داشتیم مربوط به یک حافظه پنهان در سمت سرور جهانی بود که بر روند آزمایش تأثیر می‌گذاشت.

این QA مهاجرت بر دو چیز استوار بود:

• هدف گذاری.
• بررسی تغییر مسیرهای 301.

ما زمان بیشتری را در مرحله کشف صرف کردیم تا خود مهاجرت.

چیزی که ما از این مهاجرت خاص حذف می کنیم این است که شما واقعاً باید نکات و نکات یک سایت را یاد بگیرید. کار با تیم های بزرگ و یادگیری مالک هر صفحه و نحوه مدیریت آنها (صفحات یا صاحبان صفحه) زمان زیادی می برد.

هیچ چیز خاصی مانع مهاجرت نشد، اما ما این را به زمان زیادی که در مرحله کشف صرف شده است نسبت می دهیم. اگر زمان زیادی را به این فاز اختصاص نمی دادیم، می توانست بد تمام شود.

Discovery به ما این امکان را داد که در صورت بروز مشکل در هنگام مهاجرت آماده باشیم تا بتوانیم افراد مناسب را فراخوانی کنیم و خطا را در محل برطرف کنیم.

استفاده از قالب به ما کمک زیادی کرد.

قالب

این الگوی مهاجرت تقسیم شده با آمدن پروژه های جدید و مشابه به روز خواهد شد. لطفاً به جای درخواست دسترسی، کپی خود را تهیه کنید. همچنین، در حین کار روی آن، بهبودهایی را بهبود یا پیشنهاد دهید.

نتیجه

مهاجرت ما موفقیت آمیز بود، 5 دقیقه طول کشید تا زنده بمانیم (از جمله پاک کردن تمام حافظه پنهان جهانی) و فقط 15 دقیقه برای اجرای یک خزیدن لیست برای شناسایی همه تغییر مسیرها که به درستی کار می کنند.

تعریف “موفقیت” چیزی است که هر مهاجرتی به آن نیاز دارد. در اکثر مهاجرت ها، به نظر می رسد همیشه مشکلی وجود دارد. حتی زمانی که زمان بیشتری را در مرحله راه اندازی صرف می کنید، همیشه یک جزئیات کوچک نادیده گرفته می شود.

مسلماً موفقیت این مهاجرت نسبت به سایرین در گذشته آسان‌تر بود، زیرا تنها QA واقعی مورد نیاز اطمینان از کارآمدی تغییر مسیرها بود. اتوماسیون در اینجا به بررسی موفقیت آمیز بودن همه تغییر مسیرها کمک کرد.

با این حال، این تنها بخشی از داستان است. ما همچنین قبل از اینکه پروژه را برنده بدانیم، منتظر موارد زیر بودیم:

• صفحات سایت منبع به آرامی شروع به حذف فهرست کردند.
• رتبه بندی صفحات مقصد شروع به افزایش کرد.

ما با یک حافظه پنهان سمت سرور به مشکل برخوردیم که بر روند تأیید تأثیر گذاشت و باید چند بار پاک شود. به نظر می‌رسد که حافظه‌های پنهان جهانی همیشه مشکلاتی را در حین مهاجرت ایجاد می‌کنند، بنابراین این موضوع قطعاً هنگام کار بر روی یک مهاجرت عادی یا تقسیم‌شده در آینده باید در نظر گرفته شود.

ظرف یک روز شاهد به‌روزرسانی‌هایی در نتایج جستجوی Google بودیم و بسیاری از صفحات مقصد به دلیل تغییر مسیرهای هدفمند افزایش یافتند.

---

نظرات بیان شده در این مقاله نظرات نویسنده مهمان است و لزوماً سرزمین موتور جستجو نیست. نویسندگان کارکنان در اینجا فهرست شده اند.

---