نکات کلیدی
- پیشنمایش محیط بررسی نسخهٔ در حال ساخت است. نسخهٔ منتشرشده از یک آدرس عمومی سرو میشود و باید همانجا، با تنظیمات و اتصالهای خودش آزموده شود.
- خیر. اتصال فرم، مجوز ذخیره و بازیابی رکورد بعد از بازکردن مجدد صفحه را جدا بررسی کن. وجود دکمه یا پیام موفقیت، سند این اتصال نیست.
- پس از آمادهشدن نسخهٔ عمومی و تصمیم انتشار محتوای عمومی، سیاست خزنده و تگها را هماهنگ بررسی کن. پنل و دادهٔ خصوصی نباید با این تصمیم عمومی شوند.
اگر سایت در پنجرهٔ پیشنمایش باز میشود، یک قدم مهم جلو رفتهای؛ اما هنوز سه سؤال جدا داری: آیا همین نسخه عمومی شده؟ آیا جریان اصلی کار میکند؟ آیا برای داده و کاربر واقعی آماده است؟ این مقاله کمک میکند جواب هرکدام را با یک مشاهدهٔ مشخص بنویسی، نه با حدس از ظاهر صفحه.
برای مثال، در پروژهٔ استودیوی عکاسیِ بررسیشده در کُندا، خانه و خدمات نمایش داده میشدند و فرم، ورودی خالی را تشخیص میداد. با این حال، خود پروژه دربارهٔ آمادهنبودن ذخیرهسازی توضیح داشت. این وضعیت تناقض نیست: رابط میتواند قابل بررسی باشد و اتصال عملیاتی هنوز تکمیل نشده باشد. آخرین بازبینی این راهنما ۲۵ مهر ۱۴۰۵ است؛ پروژه را برای این مقاله دوباره نساختهایم.
پاسخ سریع: برای هر وضعیت یک مدرک بخواه
برای دیدن همهٔ ستونها، جدول را افقی جابهجا کن.
| وضعیت | مدرکی که لازم داری | چیزی که ثابت نمیکند |
|---|---|---|
| پیشنمایش باز میشود | صفحه در محیط بررسی دیده میشود | آمادهبودن آدرس عمومی |
| نسخه منتشر شده | آدرس عمومی با مسیر درست باز میشود | اتصال فرم و امنیت داده |
| جریان اصلی بررسی شده | یک ورودی آزمایشی تا نتیجه پیگیری میشود | پایداری همهٔ حالتها |
| آمادهٔ استفادهٔ واقعی | معیارهای داده، نقش، خطا و عملیات پذیرفته شدهاند | بینیازی از مراقبت بعدی |
این جدول را برای پروژهٔ خودت پر کن. بهجای نوشتن «فرم درست است»، بنویس «درخواست ساختگی با حساب مدیر بازیابی شد». جملهٔ دوم هم قابل تکرار است و هم اگر بعداً خراب شود، معلوم میکند چه چیزی را باید دوباره بررسی کنی.
از رابط شروع کن؛ اما در رابط متوقف نشو
تیتر، منو و دکمه را مثل یک بازدیدکننده بخوان. برای یک سایت خدماتی، آیا روشن است چه خدمتی میفروشی و کاربر باید چه کاری انجام بدهد؟ اگر دکمهٔ «درخواست مشاوره» فقط به بالای صفحه برگردد، هنوز مسیر درخواست نداری. اگر فرم باز شود، مرحلهٔ بعد بررسی ورودی و نتیجه است.

در همین نمونه، اطلاعات تماسِ تولیدشده هم نیاز به تأیید داشت. یک شماره یا جملهٔ اطمینانبخش را صرفاً چون ابزار آن را نوشته نگه ندار. محتوای واقعی، تعهد تجاری و رفتار فنی هرکدام مسئول بررسی خودشان را دارند.
نسخهٔ اول را با معیار روشن شروع کن
یک سایت کوچک بساز و پیشنمایش، اتصال فرم و نسخهٔ عمومی را جدا بررسی کن.
نمونهٔ سایت و بررسی فرم ذخیرهٔ واقعی را با یک رفتوبرگشت بررسی کن
از دادهٔ ساختگی روشن استفاده کن؛ مثلاً نام «درخواست آزمایشی مقاله» و نشانی example.invalid. ارسال را انجام بده، نتیجه را بخوان، صفحه را دوباره باز کن و رکورد را در محل مورد انتظار پیدا کن. اگر ثبت با حساب کاربر است، بازیابی را هم با همان حساب بررسی کن. صرف باقیماندن متن در همان تب، نتیجهٔ کافی نیست.
اگر پنل مدیر داری، همان درخواست باید برای نقش مجاز در دسترس باشد. اگر داده فقط در حافظهٔ مرورگر نگه داشته میشود، این محدودیت را صریح بنویس. دادهٔ آزمایشی را با اطلاعات مشتری واقعی جایگزین نکن تا وقتی مسیر ذخیره، دسترسی و حذف برایت روشن شده است.
برای این مرحله یک یادداشت کوتاه بساز: ورودی چه بود، در کدام صفحه فرستاده شد، بعد از بازکردن مجدد کجا دیده شد، و با کدام حساب. این یادداشت از ده اسکرینشات بدون توضیح کاربردیتر است.
شکست را هم جزئی از مسیر طراحی کن
فرم خالی باید کنار همان فیلد توضیح بدهد چه چیزی لازم است. هنگام ارسال، وضعیت دکمه روشن باشد. اگر پاسخ موفق نرسید، پیام «ثبت شد» نمایش نده و دادهٔ واردشده را نگه دار. اگر محیطت دکمهٔ شبیهسازی خطا دارد، نتیجه را با همین برچسب ثبت کن؛ شبیهسازی، آزمایش قطعی واقعی شبکه نیست.
در بررسی استودیو، اعتبارسنجی ورودی خالی دیده شد. از این مشاهده نمیشود دربارهٔ دسترسی دیتابیس یا بازیابی بعد از خطای شبکه حکم داد. مطالعهٔ موردی استودیو همین مرز میان مشاهده و ادعا را با تصاویر بیشتر توضیح میدهد.
نسخهٔ عمومی را از راه مستقیم باز کن
لینک یک صفحهٔ داخلی را در تب تازه باز کن. اگر صفحهٔ خدمات فقط پس از ورود از خانه کار میکند، مسیر مستقیم هنوز مسئله دارد. منو، دکمهٔ برگشت، عکسها و فونت را روی آدرسی بررسی کن که قرار است مشتری بگیرد؛ تنظیمات محیط پیشنمایش ممکن است یک خطای مسیر یا دارایی را پنهان کند.
در توضیح رسمی MDN دربارهٔ انتشار، ساخت نسخهٔ مناسب انتشار از اجرای محیط توسعه جداست. برای تو، نتیجهٔ عملی این تفکیک یک کار ساده است: بعد از هر انتشار مهم، مسیر اصلی را روی همان نسخهٔ عمومی دوباره انجام بده. این بررسی را از روی خبر موفقیت ابزار حذف نکن.
صفحهٔ عمومی و پنل خصوصی را جدا نگه دار
خانه و معرفی خدمات میتوانند عمومی باشند؛ فهرست درخواست مشتری و پنل مدیریت معمولاً چنین نیستند. پنهانکردن یک گزینه در منو، مجوز دسترسی ایجاد نمیکند. چکلیست دسترسی وباپ روش تعریف نقش و بررسی مالک رکورد را توضیح میدهد.
برای سئو هم صفحه باید از لینکهای روشن پیدا شود و عنوان و توضیح مخصوص داشته باشد. تصمیم دربارهٔ noindex را با مرحلهٔ انتشار هماهنگ کن. صفحهٔ آزمایشی را برای گرفتن رتبه عمومی نکن و پنل خصوصی را برای اینکه «همهچیز ایندکس شود» باز نگذار. اصول جستجوی گوگل نقطهٔ شروع بررسی محتوای عمومی است.
یک برگهٔ تحویل کوچک آماده کن
پیش از فرستادن لینک، این پنج مورد را ثبت کن: آدرس نسخه، جریان بررسیشده، دادهٔ آزمایشی، ایرادهای باز و کسی که بعد از انتشار مسئله را پیگیری میکند. اگر بخشی هنوز دموست، نامش را در همان برگه بیاور. این کار اعتماد به خروجی را از یک حس مبهم به یک توافق روشن تبدیل میکند.
در کُندا میتوانی مسیر ساخت و بررسی را از یک ایدهٔ کوچک شروع کنی؛ اما انتخاب ابزار جای معیار پذیرش را نمیگیرد. برای شروع عملیتر، راهنمای ساخت سایت با هوش مصنوعی و برای بودجه، راهنمای هزینهٔ ساخت اپ را کنار همین برگه بگذار.
پرسشهای پرتکرار
پیشنمایش با سایت منتشرشده چه فرقی دارد؟
پیشنمایش محیط بررسی نسخهٔ در حال ساخت است. نسخهٔ منتشرشده از یک آدرس عمومی سرو میشود و باید همانجا، با تنظیمات و اتصالهای خودش آزموده شود.
آیا انتشار یعنی فرم به دیتابیس وصل است؟
خیر. اتصال فرم، مجوز ذخیره و بازیابی رکورد بعد از بازکردن مجدد صفحه را جدا بررسی کن. وجود دکمه یا پیام موفقیت، سند این اتصال نیست.
برای بررسی نسخهٔ عمومی از کجا شروع کنم؟
مسیر اصلی را از ابتدا انجام بده: ورود از لینک عمومی، پیدا کردن خدمت، تکمیل فرم، دریافت نتیجه و بازیابی داده با حساب مجاز.
چه زمانی noindex را بردارم؟
پس از آمادهشدن نسخهٔ عمومی و تصمیم انتشار محتوای عمومی، سیاست خزنده و تگها را هماهنگ بررسی کن. پنل و دادهٔ خصوصی نباید با این تصمیم عمومی شوند.
منابع
- انتشار اپ در MDN (۲٬۰۲۶)
- اصول جستجوی گوگل (۲٬۰۲۶)