دامنه اختصاصی آموزشگاه آنلاین | اتصال، آزمون ورود و انتقال

برای اتصال دامنهٔ آموزشگاه، DNS و HTTPS را بررسی کنید و پیش از تغییر عمومی نشانی، ورود و دسترسی هنرجو را آزمایش کنید.

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

مدیر آموزشگاه نشانی تازه‌ای برای صفحهٔ درس می‌خواهد. مسئول فنی دامنه را وصل می‌کند و صفحهٔ اصلی در مرورگر باز می‌شود. در نگاه اول کار تمام است. بعد هنرجویی لینک قدیمی درس را از پیام ثبت‌نام باز می‌کند و به صفحه‌ای می‌رسد که از او دوباره ورود می‌خواهد. پس از ورود هم دوره را پیدا نمی‌کند. این مشکل نشان می‌دهد اتصال دامنه و انتقال مسیر هنرجو دو کار جدا هستند. دامنه اختصاصی آموزشگاه آنلاین زمانی آماده است که صفحه، ورود و درس در مسیر واقعی با هم کار کنند.

ابتدا مشخص کنید فقط آدرس تازه‌ای به سامانه اضافه می‌کنید یا نشانی عمومی صفحه‌های موجود را هم تغییر می‌دهید. سپس روش اتصال را از میزبان بگیرید. رکورد DNS و گواهی HTTPS را کنترل کنید. با یک حساب مجاز و یک حساب بدون دسترسی، لینک درس را از همان پیام قدیمی باز کنید. اگر نشانی صفحات عمومی عوض می‌شود، مقصد هر صفحه و تغییرمسیر را هم جدا بررسی کنید. این راهنما برای طراحی و اجرای چنین تمرینی است. همهٔ نشانی‌های مثال فرضی‌اند و اتصال دامنه برای پلن مشخصی در این مقاله آزمایش نشده است. راهنمای عملیات آموزشگاه آنلاین

ابتدا انتخاب کنید کدام نشانی باید عوض شود

ممکن است سایت معرفی روی دامنهٔ اصلی بماند و فقط فضای درس روی یک زیردامنه قرار بگیرد. برای نمونه، example.com برای معرفی و learn.example.com برای آموزش استفاده شود. در این حالت صفحه‌های عمومی قدیمی شاید نیازی به انتقال نداشته باشند. باید مطمئن شوید لینک‌های معرفی به مقصد آموزشی می‌رسند و ورود در هر بخش مطابق طراحی کار می‌کند. گزینهٔ دیگر این است که سایت و فضای آموزش هر دو به دامنهٔ تازه بروند. در آن حالت، علاوه بر مسیر هنرجو باید تغییر نشانی صفحه‌های عمومی و اثر آن بر جست‌وجو را هم مدیریت کنید.

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

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

از فروشنده یا میزبان پاسخ مشخص بخواهید. آیا زیردامنه پذیرفته می‌شود؟ برای دامنهٔ اصلی چه رکوردی لازم است؟ مسئول صدور و تمدید گواهی کیست؟ آدرس قبلی بعد از اتصال چه رفتاری دارد؟ تغییرمسیر لینک درس در اختیار چه کسی است؟ پاسخ را برای نام پلن و دامنهٔ مورد استفاده نگه دارید. امکان اتصال پلیر یا API به یک سایت، خودبه‌خود به معنی ارائهٔ پنل کامل روی دامنهٔ اختصاصی نیست. برای برنامهٔ نخستین ترم، همین تصمیم را با زمان آماده شدن صفحه و حساب‌ها هماهنگ کنید. برنامهٔ راه‌اندازی آموزشگاه برای اولین ترم

DNS و گواهی را در دو مرحله بررسی کنید

DNS مشخص می‌کند نام دامنه به کدام مقصد اشاره کند. نوع رکورد و مقدار را از میزبان خودتان بردارید. ممکن است برای یک زیردامنه نام مستعار داده شود و برای دامنهٔ اصلی روش دیگری لازم باشد. از نمونهٔ یک فروشنده برای محیط فروشندهٔ دیگر استفاده نکنید. در برگهٔ تغییر، نام کامل رکورد، نوع، مقدار قبلی، مقدار تازه، زمان و مسئول را بنویسید. فقط رکوردهای لازم را تغییر دهید. رکوردهای ایمیل یا بخش‌های دیگر دامنه ممکن است برای کارهای مستقل استفاده شوند.

پس از ثبت رکورد، نام دامنه را از دو مسیر بررسی کنید. می‌توانید از ابزار نمایش DNS و شبکه‌ای متفاوت برای کنترل نتیجه کمک بگیرید. اگر یک شبکه هنوز مقدار قدیمی می‌بیند، زمان آخرین تغییر و شیوهٔ کش شدن پاسخ را در نظر بگیرید. صرف اینکه صفحه روی لپ‌تاپ مدیر باز می‌شود به معنی نتیجهٔ یکسان برای همه نیست. مقدار را با مقصدی که میزبان برای همان دامنه داده تطبیق دهید. در صورت اختلاف، پیش از چند بار تغییر دادن رکورد، نتیجهٔ فعلی و وضعیت تنظیم را ثبت کنید.

گواهی TLS بخش جداگانه‌ای از پذیرش است. پس از اینکه نام دامنه به مقصد می‌رسد، نشانی HTTPS را در مرورگر باز کنید. مطمئن شوید خطای نام گواهی، انقضا یا زنجیرهٔ اعتماد دیده نمی‌شود. دامنهٔ اصلی و زیردامنه‌ای را که واقعاً منتشر می‌شوند جدا امتحان کنید. همچنین اگر آدرس HTTP قبلاً در پیام‌ها استفاده شده، رفتار آن را بسنجید. باید بدانید آیا به نسخهٔ HTTPS درست می‌رسد یا مسیر دیگری را باز می‌کند. پنهان کردن هشدار مرورگر برای قبول آزمون کافی نیست.

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

ورود و ماندن در حساب را روی مقصد تازه امتحان کنید

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

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

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

برای مسیر پرداخت، یک سناریوی آزمایشی اجرا کنید. از نشانی جدید به مرحلهٔ ثبت سفارش بروید و پس از پایان آزمایشی یا لغو، نشانی بازگشت را ببینید. اگر پرداخت بیرون از سامانه انجام می‌شود، همان مسیری را امتحان کنید که هنرجو برای پیگیری پرونده می‌بیند. ورود از داخل پیام‌رسان، مرورگر معمول و گوشی را جدا آزمایش کنید. گاهی مرورگر داخلی نشست قبلی را نمی‌بیند. اگر راه جایگزین پیشنهاد می‌کنید، خودتان همان راه را از روی پیام و با حساب نمونه طی کنید.

تغییرمسیر را صفحه‌به‌صفحه طراحی کنید

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

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

برای انتقال دائمی صفحهٔ عمومی، راهنمای گوگل استفاده از تغییرمسیر دائمی سمت سرور و تطبیق آدرس قدیم و جدید را توضیح می‌دهد. مقصد نهایی باید قابل باز شدن باشد و ترجیحاً کاربر از چند تغییرمسیر غیرضروری عبور نکند. روی نشانی تازه، پیوندهای داخلی، نشانی اصلی صفحه و نقشهٔ سایت را بازبینی کنید. تغییرمسیر را به گونه‌ای بررسی کنید که نه حلقه بسازد و نه دوباره به دامنهٔ قدیمی برگردد. مسیرهای خصوصی را طبق تنظیمات خود سامانه از مسیرهای عمومی جدا نگه دارید. راهنمای انتقال سایت با تغییر نشانی در Google Search Central

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

برای انتشار محدود معیار قبول و توقف داشته باشید

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

قبل از تغییر عمومی، یک مسیر برگشت تعریف کنید. مشخص کنید اگر اتصال تازه مشکل داشت چه کسی تصمیم می‌گیرد، کدام تنظیم باید برگردد و نسخهٔ قبلی تنظیم کجاست. برگشت DNS ممکن است برای همهٔ کاربران هم‌زمان دیده نشود. برای همین به پیام پشتیبانی و راه دسترسی موقت فکر کنید. تمرین برگشت را در محیط آزمایشی یا با یک آدرس غیرعمومی انجام دهید. به جای قطع عمدی آموزش فعال، از نشانی نمونه و حساب‌های آزمایشی استفاده کنید.

یک تمرین کوتاه برای گزارش خطا داشته باشید. از نفر اول بخواهید فقط پیام هنرجو را بخواند و بگوید مشکل پیش از باز شدن صفحه، هنگام ورود یا پس از دیدن درس رخ داده است. نفر دوم باید بتواند همان مسیر را با آدرس و حساب نمونه باز کند. اگر اطلاعات کم است، دو دادهٔ لازم را مشخص کنید. معمولاً نام صفحه و زمان خطا نقطهٔ شروع بهتری از درخواست جزئیات کامل حساب‌اند. در روز انتقال همین برگه به تقسیم کار بین مسئول دامنه و پشتیبانی آموزشگاه کمک می‌کند.

نتیجهٔ فنی را در یک برگه با چند شاهد ثبت کنید

برای DNS، از مسئول فنی بخواهید نامی را که قرار است کاربر ببیند دقیق بنویسد. سپس از یک ابزار پرس‌وجوی DNS استفاده کند و پاسخ را در همان برگه نگه دارد. برای نمونه روی رایانه‌ای که ابزار مربوط را دارد، می‌توان نام میزبان و نوع رکورد مورد انتظار را با یک پرس‌وجو بررسی کرد. اگر سرویس برای زیردامنه مقصد اسمی داده است، نام مقصد را با مقدار اعلام‌شده تطبیق دهید. اگر از پروکسی یا شبکهٔ توزیع محتوا استفاده می‌کنید، پاسخ مشاهده‌شده ممکن است با نشانی سرور اصلی متفاوت باشد. ملاک را از راهنمای همان تنظیم بگیرید.

برای HTTPS، زمان مشاهده و نام میزبان را ثبت کنید. بعد یک صفحهٔ عمومی و یک مسیر ورود را روی همان میزبان باز کنید. گاهی صفحهٔ اول با HTTPS می‌آید اما فایل یا فرم از نشانی قبلی درخواست می‌شود. اگر مرورگر محتوایی را به دلیل درخواست ناامن مسدود می‌کند، در گزارش نام بخش و نتیجه را بنویسید. برای نمونه، ممکن است صفحهٔ درس باز شود اما تصویر یا فایل راهنما به دلیل آدرس قدیمی دیده نشود. رفع این مشکل به بازبینی نشانی دارایی مربوط است و با تغییر دوبارهٔ رکورد دامنه حل نمی‌شود.

برای تغییرمسیر، پاسخ اولیه و مقصد نهایی را کنار هم بگذارید. فرض کنید نشانی قدیمی معرفی دوره ابتدا به صفحه‌ای می‌رود که دوباره به همان نشانی قدیم برمی‌گردد. این حالت حلقه ایجاد می‌کند. یک حالت دیگر این است که نشانی قدیمی از راه نسخهٔ بدون HTTPS، بعد دامنهٔ میانی و سپس دامنهٔ تازه می‌گذرد. اگر این گام‌های اضافی لازم نیستند، مسیر را کوتاه کنید. سپس همان پیوند ذخیره‌شده را دوباره از گوشی باز کنید تا نتیجه فقط در ابزار بررسی نشده باشد.

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

یک برنامهٔ نمونه برای روز انتقال بنویسید

فرض کنید آموزشگاه قرار است صبح جمعه نشانی درس را عوض کند و صفحهٔ معرفی روی دامنهٔ قبلی بماند. شب قبل، فهرست لینک‌های درس و پیام خرید را ذخیره کنید. از یک حساب نمونه در محیط تازه استفاده کنید و یک ویدیو، یک فایل و یک صفحهٔ پشتیبانی را باز کنید. صبح، ابتدا تنظیم DNS و گواهی را کنترل کنید. سپس در یک نشست تازه لینک قبلی درس را باز کنید. اگر نتیجه درست است، یک سفارش آزمایشی را تا صفحهٔ وضعیت دنبال کنید. تنها پس از موفق بودن معیارهای اصلی، پیوندهای عمومی که در اختیار شما هستند تغییر کنند.

در برگهٔ روز انتقال، زمان تصمیم و مسئول هر گام را کنار هم بنویسید. برای نمونه، مسئول DNS تغییر را ثبت می‌کند. مسئول سامانه ورود و دسترسی را می‌سنجد. پشتیبان پیام آماده را با نشانی صحیح مرور می‌کند. اگر ورود درس شکست خورد، همهٔ تیم از قبل بدانند چه کسی تصمیم توقف را می‌گیرد. برای توقف، فقط برگرداندن رکورد کافی نیست. باید نتیجهٔ مرورگر و دسترسی حساب را دوباره مشاهده کنید و وضعیت را از کانالی که هنرجو واقعاً می‌بیند اعلام کنید.

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

پس از باز شدن عمومی، چند ساعت نخست را به بررسی مسیرهای اصلی اختصاص دهید. نتیجهٔ شبکه‌های مختلف را با ساعت ثبت کنید و به هر پرونده نوع خطا بدهید. اگر گزارش یک هنرجو فقط دربارهٔ صفحهٔ قدیمی است، از او نام درس و محل لینک را بپرسید. اگر چند هنرجو از یک دامنهٔ تازه با خطای گواهی روبه‌رو شده‌اند، همین اطلاعات برای اولویت‌بندی کافی است. تغییر دیگر را تا وقتی وضعیت مسیرهای اصلی روشن نشده هم‌زمان شروع نکنید، مگر اینکه برای بازیابی همان مسیر لازم باشد.

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

بعد از تغییر نشانی چه چیزهایی را دوباره ببینید؟

برای صفحه‌های عمومی، در Search Console هر دو محدودهٔ قدیم و جدید را در صورت دسترسی کنترل کنید. نقشهٔ سایت تازه را با نشانی‌های عمومی نهایی بسازید و چند صفحهٔ مهم را با URL Inspection بررسی کنید. پاسخ زنده، نشانی اصلی اعلام‌شده و وضعیت ثبت‌شده در گزارش‌ها همیشه هم‌زمان به‌روز نمی‌شوند. تاریخ مشاهده را کنار نتیجه نگه دارید و تغییر رتبه یا کلیک را پس از انتقال در بازهٔ قابل مقایسه بخوانید. برای آدرس‌های خصوصی، ورود موفق هنرجو و پاسخ دسترسی را با حساب واقعی آزمایشی بسنجید.

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

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

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