چک‌لیست تحویل وب‌سایت: کد، دامنه، محتوا و دسترسی‌ها

«سایت را تحویل گرفتم» وقتی درست است که بتوانید بدون تیم سازنده ادامه دهید. این مقاله فقط روز تحویل سایت را پوشش می‌دهد؛ برای نوشتن تحویل‌دادنی‌ها و معیار پذیرش در قرارداد، منبع جدایی لازم است و بندهای حقوقی را باید با وکیل نهایی کنید.

چرا «دریافت» کافی نیست؟

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

جدول تحویل با راستی‌آزمایی

برای تفاوت مفهومی دامنه، DNS و هاست، Domain، DNS و Hosting چه تفاوتی دارند؟ و برای تمدید گواهی، SSL و HTTPS چیست؟ را بخوانید.

دامنه و دارندهٔ ثبت

ICANN توضیح می‌دهد کسی که به‌عنوان Registered Name Holder ثبت شده، دارندهٔ رسمی دامنه است. بند 3.7.7.3 قرارداد اعتباردهی registrar (RAA 2013) می‌گوید اگر دارندهٔ ثبت استفاده از دامنه را به شخص دیگری بسپارد (مثلاً طراح سایتی که دامنه را به نام خودش برای مشتری ثبت کرده)، همچنان دارندهٔ ثبت است و در برابر استفادهٔ نادرست شخص ثالث مسئول شناخته می‌شود، مگر هویت و اطلاعات تماس کاربر واقعی را افشا کند. در «مشخصهٔ مزایا و مسئولیت‌های دارندگان دامنه» که پیوست همین قرارداد است هم آمده است باید اطلاعات تماس دقیق ارائه و به‌روز نگه داشته شود، ظرف ۱۵ روز به پرسش registrar پاسخ داده شود و اگر تمدید خودکار دارید، اطلاعات پرداخت به‌روز بماند. دقت کنید این قواعد برای دامنه‌هایی است که از registrarهای معتبر ICANN ثبت می‌شوند؛ ما قواعد دامنهٔ ir. را بررسی نکرده‌ایم و باید از ارائه‌دهندهٔ ثبت بپرسید.

Search Console و مالکیت

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

کد و بایگانی نسخه

NIST SSDF می‌گوید همهٔ اشکال کد باید در مخزن با اصل حداقل امتیاز نگه‌داری شود (PS.1.1) و فایل‌های لازم هر نسخهٔ منتشرشده به‌صورت امن بایگانی شود (PS.3.1). در تحویل سایت یعنی یک برچسب نسخه، فهرست وابستگی‌ها و دستور ساخت داشته باشید.

نقشهٔ ریدایرکت در بازطراحی

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

بعد از تحویل

1. رمزهای قدیمی و حساب‌های موقت سازنده را تغییر یا حذف کنید.
2. یادآور انقضای دامنه و گواهی را روی تقویم خودتان بگذارید.
3. یک بازیابی از بکاپ را تمرین کنید.
4. مرجع مستندات و تماس پشتیبانی را در یک سند نگه دارید؛ برای تعریف آمادگی فنی Production-Ready را ببینید.

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

باقی‌ماندهٔ مرحلهٔ توسعه: noindex و robots.txt

راهنمای Google Search Central برای انتقال سایت (که در ۱۹ اکتبر ۲۰۲۶ خوانده شد) یادآوری می‌کند بعضی تیم‌ها در مرحلهٔ توسعه کل خزش را با robots.txt می‌بندند یا از noindex استفاده می‌کنند؛ پس باید از پیش آماده باشید که این قاعده‌ها هنگام انتقال برداشته شوند. در جدول «مشکل‌های رایج» همین سند، اولین مورد همین است: noindex یا مسدودسازی robots.txt که فقط برای مهاجرت لازم بود و فراموش شده. بنابراین در فهرست تحویل بنویسید چه کسی پس از انتشار این دو را بررسی می‌کند و چگونه (مثلاً با URL Inspection برای صفحه‌هایی که در Google دیده نمی‌شوند). اگر فایل robots.txt ندارید مشکلی نیست، ولی سرور باید برای نبود آن 404 درست بدهد.

تأیید مالکیت باید از انتقال جان سالم به در ببرد

همان راهنما هشدار می‌دهد تأیید Search Console باید پس از انتقال هم کار کند: اگر از روش فایل HTML استفاده می‌کنید باید فایل تأیید فعلی را در نسخهٔ جدید هم بگذارید؛ اگر با متا تگ یا Google Analytics تأیید کرده‌اید باید CMS جدید همان‌ها را داشته باشد؛ و در کل توکن‌های تأیید ممکن است با تغییر URL عوض شوند. همچنین همهٔ نسخه‌های سایت قدیم و جدید (با و بدون www و HTTP/HTTPS) باید تأیید شوند. برای تحویل سایت، یعنی باید تأیید مالکیت را به کارفرما واگذار کنید یا حداقل یک «مالک تأییدشده» از طرف او اضافه کنید، نه فقط حساب پیمانکار. این توصیهٔ عملی با متن راهنمای تأیید مالکیت همخوان است که مالک تأییدشده را بالاترین سطح مجوز می‌داند.

قاعده‌های ریدایرکت: چه چیزی دقیقاً بنویسیم؟

سند Google برای انتقال، ریدایرکت‌های دائمی سمت سرور (مانند 301 و 308) را توصیه می‌کند و می‌گوید فقط اگر امکان‌پذیر نبود به ریدایرکت سمت کلاینت برگردید. زنجیرهٔ ریدایرکت را کوتاه نگه دارید: Googlebot تا ۱۰ گام را دنبال می‌کند ولی سند توصیه می‌کند مستقیماً به مقصد نهایی ریدایرکت کنید و اگر نشد، طول زنجیره را کم (ترجیحاً حداکثر ۳ و کمتر از ۵) نگه دارید. همچنین نباید خیلی از URLهای قدیمی را به یک مقصد نامرتبط، مثل صفحهٔ اصلی، بفرستید، چون ممکن است soft 404 تلقی شود؛ مگر اینکه چند صفحه واقعاً در یک صفحه ادغام شده باشد. محتوایی که حذف می‌شود باید 404 یا 410 بدهد. این‌ها را در فایل نقشهٔ ریدایرکت تحویلی مکتوب کنید.

پس از انتقال: پایش و مدت نگه‌داری ریدایرکت‌ها

Google می‌گوید ریدایرکت‌ها را تا جای ممکن و معمولاً دست‌کم یک سال نگه دارید تا سیگنال‌ها منتقل شوند؛ از دید کاربر حتی می‌توان آن‌ها را نامحدود نگه داشت، ولی چون ریدایرکت کند است باید پیوندهای خودتان و پیوندهای پرتردد بیرونی را به نشانی جدید تغییر دهید. در دورهٔ انتقال نوسان موقت رتبه عادی است و برای سایت متوسط ممکن است چند هفته یا بیشتر طول بکشد. برای پایش، سند Search Console (نقشهٔ سایت قدیم و جدید، گزارش ایندکس و کوئری‌ها)، لاگ‌های سرور (خطاهای HTTP و خزش Googlebot) و ابزار تحلیل را نام می‌برد. همچنین سرور باید ظرفیت خزش سنگین‌تر پس از انتقال را داشته باشد. اگر فقط مسیر داخل یک دامنه یا HTTP به HTTPS عوض شده، Change of Address لازم نیست؛ فقط برای انتقال دامنه یا زیر‌دامنه به کار می‌رود.

فهرست مدارک تحویل (پیشنهاد نویسنده)

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

منابع و مراجع

• 2013 Registrar Accreditation Agreement, Section 3.7.7.3 — ICANN، ۲۷ ژوئن ۲۰۱۱.
• Registrants’ Benefits and Responsibilities Specification (2013 Registrar Accreditation Agreement) — ICANN.
• Verify your site ownership — Google Search Console Help.
• Site Moves and Migrations (How to move a site) — Google Search Central.
• Secure Software Development Framework (SSDF) Version 1.1 (NIST SP 800-218) — NIST، فوریه ۲۰۲۲.