چکلیست تحویل سایت از شرکت طراحی سایت؛ ۲۵ موردی که باید دریافت و بررسی کنید
تحویل سایت فقط به معنی دریافت نام کاربری پنل مدیریت و مشاهده نسخه نهایی در مرورگر نیست. یک وبسایت از دامنه، هاست، فایلها، پایگاه داده، حسابهای مدیریتی، ابزارهای آماری، تنظیمات سئو، سرویسهای جانبی و مستندات فنی تشکیل شده است. اگر هنگام تحویل پروژه به یکی از این بخشها توجه نشود، ممکن است بعداً برای تمدید دامنه، انتقال سایت، رفع خطا یا همکاری با تیم جدید با مشکل روبهرو شوید.
یک تحویل اصولی باید سه نتیجه مشخص داشته باشد: سایت مطابق قرارداد کار کند، مالکیت داراییهای دیجیتال در اختیار کارفرما قرار بگیرد و اطلاعات لازم برای نگهداری یا توسعه آینده مستند شده باشد.
در این راهنما، چکلیست تحویل سایت را در قالب ۲۵ مورد بررسی میکنیم تا پیش از تأیید نهایی و تسویه پروژه، چیزی از قلم نیفتد.
هنگام تحویل سایت چه چیزهایی باید دریافت کنیم؟
کارفرما باید متناسب با نوع پروژه به دامنه، هاست یا سرور، پنل مدیریت، فایلها، پایگاه داده، مخزن کد، ابزارهای آماری و سرویسهای متصل دسترسی داشته باشد. علاوه بر این، نسخه پشتیبان، مستندات فنی، اطلاعات تمدید سرویسها و شرایط پشتیبانی نیز باید مشخص شوند.
نوع دقیق اقلام تحویلی به قرارداد و شیوه اجرای پروژه بستگی دارد. برای مثال، در یک سایت وردپرسی معمولاً دسترسی مدیریت وردپرس، هاست، دامنه و افزونهها اهمیت بیشتری دارد؛ اما در یک سایت اختصاصی، مخزن کد، مستندات استقرار، تنظیمات سرور و ساختار پایگاه داده نیز باید بررسی شوند.
| حوزه تحویل | موارد اصلی |
|---|---|
| مالکیت و دسترسی | دامنه، هاست، سرور، DNS، پنل مدیریت |
| فایلها و اطلاعات | سورسکد، دیتابیس، بکاپ، فایلهای طراحی |
| کنترل کیفیت | امکانات، فرمها، پرداخت، موبایل، سرعت و امنیت |
| سئو و تحلیل | سرچ کنسول، آنالیتیکس، نقشه سایت و تنظیمات ایندکس |
| نگهداری | مستندات، آموزش، ضمانت و قرارداد پشتیبانی |
بخش اول: مالکیت و دسترسیهای سایت
۱. مالکیت دامنه را بررسی کنید
دامنه یکی از مهمترین داراییهای دیجیتال کسبوکار است. ایمیل و مشخصات ثبتکننده دامنه باید متعلق به کارفرما یا مجموعهای باشد که رسماً از طرف او مسئول نگهداری دامنه است.
براساس توضیحات ICANN درباره ثبتکنندگان دامنه، فرد یا سازمانی که دامنه را ثبت میکند، بهعنوان Registrant شناخته میشود و مدیریت دامنه را از طریق شرکت ثبتکننده انجام میدهد. اگر دامنه با اطلاعات شخصی طراح یا شرکت پیمانکار ثبت شده باشد، انتقال یا تمدید آن در آینده میتواند دشوار شود.
نام ثبتکننده، ایمیل بازیابی، شماره تماس، تاریخ انقضا و وضعیت قفل انتقال دامنه را بررسی کنید. برای دامنههای ملی نیز شناسه مربوط به مالک باید در اختیار کارفرما باشد.
۲. دسترسی پنل ثبت دامنه را دریافت کنید
داشتن مالکیت دامنه بدون دسترسی به پنل ثبتکننده کافی نیست. کارفرما باید بتواند تاریخ انقضا، Name Serverها، قفل انتقال، اطلاعات تماس و تنظیمات تمدید را مشاهده کند.
پس از دریافت دسترسی، ایمیل بازیابی، شماره تماس و رمز عبور را بررسی کنید. در صورت امکان، احراز هویت دومرحلهای را فعال کرده و کدهای بازیابی را در محل امن نگه دارید.
۳. دسترسی هاست یا سرور را تحویل بگیرید
اگر سایت روی هاست اشتراکی قرار دارد، دسترسی کنترلپنل مانند cPanel یا DirectAdmin باید مشخص باشد. در پروژههای اختصاصی ممکن است دسترسی SSH، پنل ابری، VPS یا سرویس مدیریتشده نیز وجود داشته باشد.
مشخصات شرکت ارائهدهنده، پلن سرویس، منابع سرور، تاریخ تمدید، مبلغ تمدید و مسئول پرداخت را ثبت کنید. اگر چند سایت روی یک حساب میزبانی میشوند، بهجای دریافت دسترسی کلی، بهتر است حساب یا سطح دسترسی مستقلی برای پروژه ایجاد شود.
۴. دسترسی DNS و CDN را بررسی کنید
ممکن است تنظیمات DNS دامنه در پنل ثبتکننده نباشد و از سرویسهایی مانند Cloudflare استفاده شود. در این شرایط، کارفرما باید به حساب مربوط دسترسی مدیریتی داشته باشد.
رکوردهای اصلی شامل A، AAAA، CNAME، MX و TXT را بررسی کنید. تغییر اشتباه این رکوردها میتواند سایت، ایمیل سازمانی یا سرویسهای تأیید دامنه را از دسترس خارج کند. بهتر است هنگام تحویل، یک خروجی یا تصویر از تنظیمات فعلی DNS نیز ذخیره شود.
۵. حساب مدیر اصلی سایت را دریافت کنید
کارفرما باید یک حساب مدیریتی مستقل با ایمیل سازمانی خود داشته باشد. استفاده مشترک چند نفر از یک نام کاربری، کنترل تغییرات و پیگیری فعالیتها را دشوار میکند.
پس از ورود، نقش و سطح دسترسی حساب را بررسی کنید. سپس رمز عبور موقت را تغییر دهید و در صورت پشتیبانی سیستم، احراز هویت دومرحلهای را فعال کنید. حسابهای آزمایشی، توسعهدهندگان قبلی و کاربران ناشناس نیز باید بازبینی شوند.
۶. دسترسی مخزن سورسکد را مشخص کنید
در سایتهای اختصاصی، سورسکد معمولاً در یک مخزن Git نگهداری میشود. مشخص کنید مخزن در چه سرویسی قرار دارد، مالک آن چه کسی است و چه افرادی به آن دسترسی دارند.
بهتر است مخزن اصلی زیر حساب سازمانی کارفرما قرار بگیرد و توسعهدهندگان از طریق دسترسیهای قابل حذف با آن همکاری کنند. وجود تاریخچه تغییرات، شاخه نسخه نهایی و برچسب نسخه منتشرشده، نگهداری و توسعه بعدی پروژه را آسانتر میکند.
۷. حساب سرویسهای جانبی را تحویل بگیرید
بسیاری از سایتها به درگاه پرداخت، پنل پیامک، ایمیل تراکنشی، نقشه، فضای ذخیرهسازی، سرویس احراز هویت، چت آنلاین یا APIهای خارجی متصل هستند.
نام سرویس، مالک حساب، سطح دسترسی، هزینه تمدید، محدودیت مصرف و روش بازیابی هر حساب باید مشخص شود. کلیدهای API و اطلاعات محرمانه نباید داخل پیامرسان یا فایل عمومی قرار بگیرند؛ این اطلاعات باید از مسیر امن منتقل و پس از تحویل، در صورت امکان تعویض شوند.
بخش دوم: فایلها، اطلاعات و نسخه پشتیبان
۸. نسخه نهایی سورسکد سایت را دریافت کنید
تحویل سورسکد باید مطابق قرارداد انجام شود. در پروژه اختصاصی، نسخه تحویلی باید همان نسخهای باشد که روی سرور اصلی اجرا شده است، نه یک فایل قدیمی یا ناقص.
در سایتهای وردپرسی نیز فایلهای قالب اختصاصی، افزونههای سفارشی و تغییرات انجامشده باید قابل دسترسی باشند. اگر بخشی از پروژه براساس نرمافزار دارای مجوز استفاده شده است، نوع مجوز و محدودیتهای آن را مشخص کنید.
۹. خروجی کامل پایگاه داده را دریافت کنید
بخش زیادی از اطلاعات سایت، از کاربران و محصولات گرفته تا سفارشها و تنظیمات، در پایگاه داده ذخیره میشود. بنابراین داشتن فایلهای سایت بدون دیتابیس، نسخه پشتیبان کاملی محسوب نمیشود.
یک خروجی سالم از پایگاه داده تهیه کنید و مطمئن شوید با نسخه فعلی سایت هماهنگ است. این فایل ممکن است اطلاعات حساس داشته باشد؛ بنابراین باید رمزگذاری شده و فقط در اختیار افراد مجاز قرار بگیرد.
۱۰. نسخه پشتیبان کامل سایت را تحویل بگیرید
بکاپ تحویلی باید فایلها، پایگاه داده و تنظیمات ضروری پروژه را پوشش دهد. بهتر است یک نسخه خارج از سرور اصلی نگهداری شود؛ زیرا بکاپی که فقط روی همان سرور قرار دارد، در صورت خرابی یا حذف سرور قابل استفاده نخواهد بود.
تاریخ تهیه بکاپ، محل نگهداری، دوره نگهداری نسخهها و روش بازیابی آن را مستند کنید. وجود فایل بکاپ بهتنهایی کافی نیست؛ باید بتوان آن را بازیابی کرد.
۱۱. فایل تنظیمات و متغیرهای محیطی را مستند کنید
پروژههای اختصاصی معمولاً برای اتصال به دیتابیس، سرویس ایمیل، فضای ذخیرهسازی و APIها از متغیرهای محیطی استفاده میکنند. نام متغیرهای موردنیاز باید مستند شود، اما اطلاعات واقعی و محرمانه نباید داخل مخزن عمومی قرار بگیرد.
بهتر است یک فایل نمونه مانند .env.example بدون رمزها و کلیدهای واقعی وجود داشته باشد. اطلاعات اصلی نیز باید در یک ابزار امن مدیریت رمز یا Secrets Manager نگهداری شود.
۱۲. فایلهای طراحی و داراییهای گرافیکی را دریافت کنید
لوگو، آیکنها، تصاویر اختصاصی، فونتها، فایلهای رابط کاربری و طرحهای نهایی بخشی از داراییهای پروژه هستند. مشخص کنید کدام فایلها باید طبق قرارداد تحویل داده شوند و مجوز استفاده از تصاویر، فونتها و افزونهها چگونه است.
اگر طراحی در Figma یا ابزار مشابه انجام شده، دسترسی مشاهده یا ویرایش فایل اصلی را دریافت کنید. داشتن فقط خروجی JPG یا PDF برای توسعه آینده کافی نیست.
بخش سوم: تست عملکرد و کیفیت سایت
۱۳. تمام صفحات و امکانات توافقشده را بررسی کنید
فهرست امکانات قرارداد یا صورتجلسات پروژه را مقابل نسخه نهایی قرار دهید. صفحات اصلی، جستوجو، فیلترها، ثبتنام، ورود، پنل کاربران، مدیریت محتوا و سایر قابلیتها باید جداگانه آزمایش شوند.
بررسی ظاهری صفحه اصلی کافی نیست. هر قابلیت باید با ورودی واقعی تست شود تا مشخص شود نتیجه مورد انتظار را تولید میکند.
۱۴. فرمها و اعلانها را آزمایش کنید
فرم تماس، درخواست مشاوره، ثبت سفارش، عضویت، بازیابی رمز و خبرنامه را ارسال کنید. سپس بررسی کنید اطلاعات در پنل ذخیره شده و پیامهای ایمیل یا پیامک به مقصد درست رسیده باشند.
پیامهای خطا نیز باید واضح باشند. فرم نباید پس از ثبت موفق، کاربر را بدون تأیید رها کند یا اطلاعات حساس را در آدرس صفحه نمایش دهد.
۱۵. پرداخت آنلاین و فرایند سفارش را تست کنید
در سایت فروشگاهی یا خدماتی، یک خرید آزمایشی کامل انجام دهید. افزودن محصول به سبد، استفاده از کد تخفیف، محاسبه هزینه، انتقال به درگاه، بازگشت از پرداخت و ثبت سفارش باید بررسی شود.
حالتهای پرداخت موفق، ناموفق و لغوشده را جداگانه آزمایش کنید. مبلغ تراکنش، شماره سفارش، وضعیت موجودی و اعلانهای مدیر و مشتری نیز باید با یکدیگر سازگار باشند.
۱۶. نمایش سایت در موبایل و مرورگرهای مختلف را بررسی کنید
سایت باید در اندازههای مختلف صفحه قابل استفاده باشد. منو، دکمهها، جدولها، فرمها، تصاویر و پنجرههای بازشو را روی موبایل واقعی آزمایش کنید.
فقط کوچککردن پنجره مرورگر معیار کافی نیست. سایت را حداقل در مرورگرهای رایج و روی چند دستگاه بررسی کنید. گوگل نیز در مستندات Mobile-first Indexing تأکید میکند که محتوای اصلی و دسترسی موتور جستوجو در نسخه موبایل باید حفظ شود.
۱۷. سرعت و عملکرد فنی سایت را بسنجید
صفحات مهم را با اینترنت و دستگاههای مختلف باز کنید. تصاویر سنگین، اسکریپتهای اضافی، فونتها و درخواستهای شبکه میتوانند تجربه کاربر را ضعیف کنند.
ابزار Lighthouse امکان بررسی خودکار عملکرد، دسترسپذیری و برخی موارد سئو را فراهم میکند. بااینحال یک امتیاز آزمایشگاهی بهتنهایی کافی نیست و نتیجه باید در کنار تجربه واقعی کاربران و گزارش Core Web Vitals بررسی شود.
۱۸. HTTPS و گواهی امنیتی را کنترل کنید
تمام صفحات سایت باید با HTTPS باز شوند و نسخه HTTP به نشانی امن منتقل شود. وجود قفل مرورگر را در صفحات اصلی، فرمها و پرداخت بررسی کنید.
همچنین تاریخ انقضا و روش تمدید گواهی مشخص باشد. در صورت استفاده از تمدید خودکار، عملکرد آن باید آزمایش شود. سرویسهایی مانند Let’s Encrypt برای ایجاد اتصال HTTPS گواهی TLS ارائه میکنند، اما نصب و تمدید صحیح همچنان باید کنترل شود.
۱۹. کاربران، رمزها و دسترسیهای اضافی را بازبینی کنید
حسابهای قدیمی، آزمایشی یا بدون استفاده را حذف یا غیرفعال کنید. هر فرد فقط باید به بخشهایی دسترسی داشته باشد که برای وظیفه او ضروری است.
رمزهای مشترک را تغییر دهید و کلیدهایی را که در دوره توسعه در اختیار افراد مختلف بودهاند، در صورت امکان تعویض کنید. OWASP نیز در راهنمای امنیت پایگاه داده، بازبینی دورهای حسابها و مجوزها و حذف دسترسیهای غیرضروری را توصیه میکند.
بخش چهارم: سئو و ابزارهای تحلیل
۲۰. دسترسی مالک سرچ کنسول را دریافت کنید
کارفرما نباید فقط بهعنوان کاربر محدود به Google Search Console اضافه شود. بهتر است حساب سازمانی او بهعنوان Verified Owner ثبت شده باشد.
طبق راهنمای رسمی Search Console، مالک تأییدشده بالاترین سطح دسترسی را دارد و میتواند کاربران، تنظیمات و ابزارهای Property را مدیریت کند. پس از دریافت دسترسی، کاربران قبلی و روشهای تأیید مالکیت را نیز بررسی کنید.
۲۱. دسترسی Google Analytics و Tag Manager را بررسی کنید
حساب Google Analytics بهتر است از ابتدا با ایمیل کارفرما ایجاد شود. اگر حساب توسط شرکت طراح ساخته شده، دسترسی مناسب برای حساب سازمانی کارفرما تعریف کنید.
گوگل امکان مدیریت کاربران و نقشها را در سطح Account و Property فراهم کرده است. تنظیمات کاربران را میتوان از بخش Access Management بررسی کرد. در صورت استفاده از Google Tag Manager نیز مالکیت Container و دسترسی انتشار باید مشخص باشد.
۲۲. نقشه سایت و فایل robots.txt را کنترل کنید
نشانی نقشه XML سایت را دریافت کرده و بازشدن آن را بررسی کنید. سپس مطمئن شوید Sitemap در Search Console ثبت شده است. گوگل توضیح میدهد که نقشه سایت به کشف بهتر URLها کمک میکند، اما ایندکسشدن همه صفحات را تضمین نمیکند.
فایل robots.txt نیز باید بررسی شود تا بخشهای مهم سایت بهاشتباه مسدود نشده باشند. توجه داشته باشید که براساس راهنمای گوگل، robots.txt ابزار قطعی جلوگیری از ایندکس نیست؛ برای این کار باید از noindex یا محدودیت دسترسی مناسب استفاده شود.
۲۳. تنظیمات پایه سئو و ایندکس صفحات را بررسی کنید
عنوان سئو، متادیسکریپشن، تگهای هدینگ، نشانی صفحات، canonical، ریدایرکتها و وضعیت ایندکس صفحات مهم باید بررسی شوند. صفحات آزمایشی، نتایج جستوجوی داخلی و URLهای تکراری نباید بدون تصمیم مشخص در دسترس موتور جستوجو قرار بگیرند.
اگر سایت قبلی به نسخه جدید منتقل شده، ریدایرکت URLهای قدیمی اهمیت زیادی دارد. همچنین دادههای ساختاریافته باید با محتوای واقعی صفحه هماهنگ باشند. گوگل از Structured Data برای درک بهتر محتوا و نمایش برخی نتایج غنی استفاده میکند، اما وجود اسکیما رتبه یا Rich Result را تضمین نمیکند.
بخش پنجم: مستندات، آموزش و پشتیبانی
۲۴. آموزش مدیریت سایت و مستندات فنی را دریافت کنید
کارفرما باید بتواند فعالیتهای روزمره مانند افزودن محتوا، مدیریت کاربران، مشاهده سفارشها، تهیه گزارش و بارگذاری تصویر را انجام دهد.
آموزش میتواند بهصورت جلسه حضوری، آنلاین، ویدئو یا فایل راهنما ارائه شود. در پروژههای اختصاصی، مستندات نصب، استقرار، ساختار پروژه، سرویسهای زمانبندیشده و روش بهروزرسانی نیز اهمیت دارند.
۲۵. صورتجلسه تحویل، ضمانت و شرایط پشتیبانی را مشخص کنید
در پایان پروژه، اقلام تحویلشده، ایرادهای باقیمانده و مسئول هر اقدام را در یک صورتجلسه ثبت کنید. مدت رفع اشکال، زمان پاسخگویی، هزینه پشتیبانی، موارد خارج از قرارداد و شرایط توسعه امکانات جدید نیز باید شفاف باشند.
ضمانت رفع خطا با پشتیبانی و توسعه یکسان نیست. رفع اشکالی که از اجرای اولیه پروژه ناشی شده، با افزودن قابلیت جدید یا تغییرات درخواستی تفاوت دارد. تعریف دقیق این موارد از اختلافهای بعدی جلوگیری میکند.
آیا شرکت طراحی سایت موظف به تحویل سورسکد است؟
پاسخ این سؤال به قرارداد، نوع پروژه و مجوز نرمافزارهای استفادهشده بستگی دارد. در پروژه اختصاصی ممکن است تحویل کامل سورسکد بخشی از قرارداد باشد؛ اما در سرویسهای اشتراکی، سایتسازها یا نرمافزارهای دارای لایسنس، مالکیت و امکان انتقال میتواند محدود باشد.
به همین دلیل، وضعیت سورسکد باید پیش از شروع پروژه مشخص شود. قرارداد بهتر است درباره مالکیت کد اختصاصی، دسترسی به مخزن، حق تغییر، امکان انتقال به تیم دیگر و محدودیت اجزای شخص ثالث توضیح روشنی داشته باشد.
چه زمانی تسویه نهایی پروژه انجام شود؟
تسویه نهایی بهتر است مطابق مراحل تعیینشده در قرارداد و پس از تکمیل تست پذیرش انجام شود. در تست پذیرش، امکانات توافقشده بررسی میشوند و ایرادهای باقیمانده در یک فهرست مشخص ثبت خواهند شد.
وجود چند اصلاح جزئی همیشه به معنی تحویلنشدن پروژه نیست؛ اما مشکلاتی مانند نبود دسترسی دامنه، خرابی فرایند پرداخت، تحویلنشدن فایلهای توافقشده یا نقص جدی امنیتی باید پیش از تأیید نهایی تعیین تکلیف شوند.
اشتباهات رایج هنگام تحویل گرفتن سایت
یکی از رایجترین اشتباهات این است که کارفرما فقط ظاهر سایت را بررسی میکند. سایتی که زیبا دیده میشود ممکن است بکاپ سالم، مالکیت دامنه، تنظیمات سئو یا مستندات کافی نداشته باشد.
پرداخت کامل پیش از انجام تستها، استفاده از حسابهای شخصی توسعهدهنده، نامشخصبودن هزینه تمدید سرویسها، تحویلنگرفتن دیتابیس و حذفنکردن کاربران آزمایشی نیز از مشکلات متداول هستند.
بهتر است فرایند تحویل در یک جلسه مشخص انجام شود و نتیجه هر مورد بهصورت «تأییدشده»، «نیازمند اصلاح» یا «نامرتبط با پروژه» ثبت شود.
سؤالات متداول درباره تحویل سایت
مهمترین دسترسیهایی که باید از طراح سایت بگیریم چیست؟
دسترسی دامنه، هاست یا سرور، پنل مدیریت سایت، DNS، سرچ کنسول، آنالیتیکس و سرویسهای جانبی از مهمترین موارد هستند. در پروژه اختصاصی، دسترسی مخزن سورسکد نیز اهمیت دارد.
آیا دریافت رمز پنل وردپرس برای تحویل سایت کافی است؟
خیر. پنل وردپرس فقط یکی از بخشهای سایت است. کارفرما باید وضعیت مالکیت دامنه، هاست، بکاپ، افزونهها، ابزارهای سئو و حسابهای متصل را نیز بررسی کند.
آیا باید فایل بکاپ سایت را دریافت کنیم؟
بله. بهتر است هنگام تحویل، یک نسخه پشتیبان کامل از فایلها و پایگاه داده دریافت و امکان بازیابی آن بررسی شود.
مالک دامنه باید کارفرما باشد یا شرکت طراحی سایت؟
در حالت معمول بهتر است دامنه با اطلاعات کارفرما یا شرکت سفارشدهنده ثبت شود و طراح فقط دسترسی فنی موردنیاز را داشته باشد. شرایط نهایی باید در قرارداد مشخص شود.
تحویل سایت چقدر زمان میبرد؟
زمان تحویل به پیچیدگی پروژه بستگی دارد. سایتهای ساده ممکن است در یک جلسه تحویل شوند، اما پروژههای اختصاصی به تست، انتقال دسترسیها، آموزش و مستندسازی بیشتری نیاز دارند.
بعد از تحویل سایت، دسترسی شرکت طراحی باید حذف شود؟
این موضوع به قرارداد پشتیبانی بستگی دارد. اگر همکاری ادامه ندارد، دسترسیهای غیرضروری باید حذف شوند. اگر پشتیبانی ادامه دارد، بهتر است برای شرکت پشتیبان حساب مستقل با سطح دسترسی مشخص ایجاد شود.
چگونه مطمئن شویم سایت آماده تحویل است؟
امکانات قرارداد را با نسخه نهایی تطبیق دهید، فرمها و پرداخت را آزمایش کنید، نسخه موبایل را بررسی کنید و از دریافت دسترسیها، بکاپ، مستندات و ابزارهای سئو مطمئن شوید. ثبت نتیجه در صورتجلسه تحویل نیز ضروری است.
جمعبندی
چکلیست تحویل سایت به کارفرما کمک میکند علاوه بر ظاهر و امکانات، مالکیت و قابلیت نگهداری پروژه را نیز بررسی کند. دامنه، هاست، سورسکد، دیتابیس، بکاپ، امنیت، سرعت، ابزارهای سئو و شرایط پشتیبانی همگی بخشی از تحویل نهایی هستند.








