اگر طراح سایت شما فردا ناپدید شود چه می‌شود؟ راهنمای مالکیت و کنترل کامل سایت
تصور کنید یک روز صبح وارد محل کار می‌شوید و متوجه می‌شوید سایت شرکت باز نمی‌شود.
با شرکت یا فردی که سال‌ها سایت را مدیریت می‌کرد تماس می‌گیرید، اما پاسخی دریافت نمی‌کنید.
اولین سؤال شما احتمالاً این است:
«رمز سایت دست کیه؟»
اما خیلی زود متوجه می‌شوید مسئله فقط رمز ورود به پنل سایت نیست.
دامنه کجاست؟
هاست به نام چه کسی است؟
اطلاعات ورود به سرور را چه کسی دارد؟
بکاپ‌ها کجا ذخیره شده‌اند؟
کد سایت در اختیار چه کسی است؟
دیتابیس کجاست؟
درگاه پرداخت با چه حسابی مدیریت می‌شود؟
Google Search Console به چه حسابی متصل است؟
ایمیل‌های سازمانی چطور؟
اگر سایت با وردپرس ساخته شده، حساب Administrator در اختیار چه کسی است؟
و مهم‌تر از همه:
اگر فرد یا شرکتی که سایت را ساخته دیگر همکاری نکند، آیا کسب‌وکار شما بدون او می‌تواند سایتش را مدیریت، منتقل یا بازیابی کند؟
این همان نقطه‌ای است که تفاوت بین «داشتن یک سایت» و «کنترل داشتن بر سایت» مشخص می‌شود.
بسیاری از کسب‌وکارها هزینه طراحی سایت را پرداخت می‌کنند، محتوای سایت را تولید می‌کنند، مشتری جذب می‌کنند و حتی سال‌ها از وب‌سایت خود استفاده می‌کنند؛ اما اطلاعات حیاتی مربوط به زیرساخت و حساب‌های اصلی در اختیار یک فرد، کارمند سابق یا شرکت پیمانکار باقی می‌ماند.
این موضوع الزاماً به معنی رفتار نادرست طراح سایت نیست. گاهی به دلیل بی‌تجربگی کارفرما، نبود قرارداد دقیق، استفاده از حساب شخصی یا صرفاً بی‌نظمی در مدیریت پروژه اتفاق می‌افتد.
اما نتیجه یکی است:
کسب‌وکار به یک شخص یا شرکت وابسته می‌شود.
در این مقاله قرار نیست بگوییم «به شرکت طراحی سایت اعتماد نکنید».
برعکس، یک رابطه حرفه‌ای می‌تواند سال‌ها ادامه داشته باشد و شرکت طراحی سایت همچنان مدیریت، پشتیبانی و توسعه پروژه را انجام دهد.
مسئله این است که حتی در یک همکاری کاملاً حرفه‌ای، مالک کسب‌وکار باید بداند چه دارایی‌هایی دارد، هرکدام کجا هستند و چه کسی به آنها دسترسی دارد.
اگر طراح سایت شما فردا ناپدید شود چه اتفاقی می‌افتد؟
این سؤال شاید کمی افراطی به نظر برسد، اما برای بررسی وضعیت مالکیت سایت، سؤال بسیار خوبی است.
فرض کنید شرکت طراحی سایت شما به هر دلیلی دیگر فعالیت نمی‌کند.
یا مدیر پروژه تغییر کرده است.
یا فردی که سایت را برای شما ساخته دیگر در شرکت حضور ندارد.
یا تصمیم گرفته‌اید پشتیبانی سایت را به مجموعه دیگری بسپارید.
در یک وضعیت حرفه‌ای، تغییر پیمانکار نباید به معنی از دست دادن کسب‌وکار دیجیتال باشد.
شما باید بتوانید با حفظ اطلاعات و دسترسی‌های اصلی:
- دامنه را مدیریت کنید؛
- هاست یا سرور را تغییر دهید؛
- سایت را به شرکت دیگری منتقل کنید؛
- بکاپ را بازیابی کنید؛
- حساب‌های سازمانی را مدیریت کنید؛
- دسترسی افراد قبلی را حذف کنید؛
- اطلاعات سایت را حفظ کنید؛
- ابزارهای تحلیل و سئو را در اختیار داشته باشید؛
- و در صورت نیاز، توسعه سایت را به تیم دیگری بسپارید.
برای دامنه‌های تحت سیاست‌های ICANN، ثبت‌کننده دامنه حقوق مشخصی در زمینه مدیریت و انتقال دامنه دارد و برای انتقال نیز وضعیت ثبت‌کننده و اطلاعات تماس اهمیت دارد.
بنابراین اولین سؤال مهم این نیست که:
«طراح سایت من چه کسی است؟»
بلکه باید پرسید:
«اگر فردا طراح سایت من عوض شود، آیا دارایی‌های دیجیتال کسب‌وکار همچنان تحت کنترل خودم باقی می‌ماند؟»
اگر پاسخ این سؤال را نمی‌دانید، احتمالاً وقت آن رسیده که وضعیت مالکیت و دسترسی‌های سایت را بررسی کنید.
مالک واقعی یک وب‌سایت چه کسی است؟
پاسخ این سؤال به این سادگی نیست که بگوییم:
«کسی که پول سایت را داده، مالک سایت است.»
یک وب‌سایت معمولاً از چندین دارایی و حساب مختلف تشکیل شده است.
برای مثال:
- دامنه
- هاست یا سرور
- فایل‌های سایت
- کد و نرم‌افزار
- دیتابیس
- محتوای متنی
- تصاویر و فایل‌های گرافیکی
- حساب مدیریت CMS
- ایمیل‌های سازمانی
- گواهی SSL
- حساب‌های تحلیل
- Search Console
- درگاه پرداخت
- APIها
- سرویس‌های پیامکی
- سیستم بکاپ
- حساب‌های تبلیغاتی
ممکن است یک شرکت همه این موارد را برای شما راه‌اندازی کرده باشد، اما این به معنی آن نیست که همه حساب‌ها باید به نام همان شرکت یا در اختیار شخصی خارج از سازمان باقی بماند.
یک مثال ساده
فرض کنید شرکت «الف» برای یک فروشگاه اینترنتی سایت طراحی کرده است.
دامنه را شرکت طراحی خریده.
هاست را هم خودش تهیه کرده.
Search Console با Gmail مدیر شرکت طراحی ساخته شده.
بکاپ‌ها روی فضای ذخیره‌سازی شخصی همان شرکت قرار گرفته‌اند.
پنل مدیریت سایت هم فقط یک حساب Administrator دارد که نام کاربری آن متعلق به طراح است.
در ظاهر، سایت کاملاً فعال است.
اما اگر فردا همکاری متوقف شود، صاحب کسب‌وکار ممکن است برای دسترسی به چند بخش حیاتی پروژه با مشکل مواجه شود.
پس بهتر است مفهوم مالکیت را به چند سؤال جدا تقسیم کنیم:
چه کسی دامنه را کنترل می‌کند؟
چه کسی زیرساخت را کنترل می‌کند؟
چه کسی به اطلاعات سایت دسترسی دارد؟
چه کسی حساب‌های اصلی را مدیریت می‌کند؟
چه کسی می‌تواند سایت را به ارائه‌دهنده دیگری منتقل کند؟
این نگاه بسیار دقیق‌تر از استفاده ساده از عبارت «مالک سایت» است.
چرا پرداخت هزینه طراحی سایت به‌تنهایی به معنی مالکیت کامل نیست؟
پرداخت هزینه طراحی سایت یک بخش مهم از رابطه تجاری میان کارفرما و مجری است، اما نباید تصور کرد که با پرداخت فاکتور، تمام موضوعات فنی و دسترسی‌ها خودکار حل شده‌اند.
مثلاً ممکن است یک کسب‌وکار برای طراحی سایت هزینه کرده باشد، اما:
- دامنه با حساب دیگری ثبت شده باشد؛
- هاست توسط پیمانکار تهیه شده باشد؛
- اطلاعات ورود به سرور مستندسازی نشده باشد؛
- کد پروژه در مخزن خصوصی پیمانکار باشد؛
- بکاپ‌ها در اختیار کارفرما نباشد؛
- حساب Search Console با ایمیل شخص دیگری ساخته شده باشد؛
- یا دسترسی‌های افراد قبلی همچنان فعال باشد.
در چنین شرایطی، مسئله اصلی دیگر «قیمت طراحی سایت» نیست؛ مسئله مدیریت دارایی‌های دیجیتال و دسترسی به آنها است.
به همین دلیل، در یک پروژه حرفه‌ای بهتر است از همان ابتدای کار مشخص شود:
- چه حساب‌هایی ایجاد می‌شوند؟
- صاحب اصلی هر حساب چه کسی است؟
- اطلاعات ورود اصلی کجا نگهداری می‌شود؟
- چه افرادی دسترسی اجرایی دارند؟
- در پایان همکاری چه اطلاعاتی باید تحویل شود؟
- فرایند انتقال یا تغییر دسترسی چگونه انجام خواهد شد؟
- بکاپ‌ها کجا نگهداری می‌شوند؟
- چه کسی مسئول تمدید دامنه و سرویس‌هاست؟
این موارد کمک می‌کنند رابطه میان کارفرما و مجری به جای وابستگی، بر اساس همکاری حرفه‌ای و شفافیت شکل بگیرد.
۱۲ دارایی که باید تحت کنترل کسب‌وکار شما باشند
اگر مدیر یک کسب‌وکار هستید، بهتر است فقط به «رمز ورود به سایت» فکر نکنید.
حداقل باید بدانید وضعیت این دارایی‌ها چیست:
| دارایی | چرا مهم است؟ | چه چیزی باید مشخص باشد؟ |
| دامنه | آدرس اصلی برند در اینترنت | ثبت‌کننده و حساب مدیریت |
| هاست/سرور | محل اجرای سایت | مالک حساب و اطلاعات دسترسی |
| کد سایت | پایه فنی پروژه | محل نگهداری و دسترسی |
| دیتابیس | محل نگهداری داده‌ها | دسترسی و روش پشتیبان‌گیری |
| CMS | مدیریت محتوای سایت | حساب مدیر اصلی |
| ایمیل سازمانی | ارتباطات رسمی | مدیر حساب و بازیابی |
| Search Console | اطلاعات عملکرد جست‌وجو | مالک و کاربران |
| Analytics | تحلیل رفتار کاربران | مالک حساب |
| درگاه پرداخت | دریافت وجه | حساب و دسترسی قانونی |
| APIها | ارتباط با سرویس‌های دیگر | کلیدها و مالکیت حساب |
| بکاپ | امکان بازیابی سایت | محل و مسئول نگهداری |
| فایل‌های طراحی | دارایی بصری برند | محل نگهداری فایل‌های اصلی |
این فهرست برای همه کسب‌وکارها دقیقاً یکسان نیست؛ بعضی سایت‌ها سرویس‌های بیشتری دارند و بعضی کمتر.
اما اصل مهم ثابت است:
باید بدانید چه دارایی‌هایی در پروژه شما وجود دارد و کنترل هرکدام دست چه کسی است.
دامنه سایت؛ مهم‌ترین دارایی‌ای که نباید از کنترل شما خارج شود
دامنه فقط یک آدرس اینترنتی نیست.
برای بسیاری از کسب‌وکارها، دامنه بخشی از هویت برند و مسیر دسترسی مشتریان به کسب‌وکار است.
اگر سال‌ها روی یک دامنه محتوا، لینک، اعتبار برند و مشتری ساخته باشید، از دست دادن کنترل آن می‌تواند پیامدهای جدی برای فعالیت آنلاین داشته باشد.
به همین دلیل، اولین چیزی که باید بررسی کنید این است:
دامنه به نام چه کسی ثبت شده است؟
همچنین باید بدانید:
- حساب کاربری ثبت‌کننده دامنه کجاست؟
- ایمیل بازیابی آن چیست؟
- تمدید دامنه چگونه انجام می‌شود؟
- اطلاعات تماس ثبت‌کننده به‌روز است؟
- چه کسی می‌تواند DNS را تغییر دهد؟
- چه کسی می‌تواند فرایند انتقال دامنه را آغاز کند؟
در دامنه‌های مشمول سیاست‌های ICANN، Registered Name Holder یا دارنده ثبت‌شده نقش مهمی در انتقال دامنه دارد و برای انتقال بین ثبت‌کنندگان نیز فرایند احراز و مجوز وجود دارد.
یک اشتباه رایج
گاهی کسب‌وکار برای راحتی کار، خرید دامنه را به طراح سایت می‌سپارد و بعد دیگر هیچ‌وقت اطلاعات ثبت دامنه را بررسی نمی‌کند.
این کار لزوماً مشکل‌زا نیست اگر رابطه و قرارداد کاملاً شفاف باشد و اطلاعات لازم در اختیار صاحب کسب‌وکار نیز قرار بگیرد.
اما اگر بعد از چند سال حتی ندانید:
«دامنه من کجا ثبت شده؟»
این یک علامت جدی برای بررسی وضعیت دارایی‌های دیجیتال است.
هاست و سرور؛ سایت شما دقیقاً روی چه زیرساختی قرار دارد؟
دامنه فقط آدرس است.
سایت برای اجرا به زیرساخت نیاز دارد؛ بسته به نوع پروژه ممکن است این زیرساخت یک هاست اشتراکی، VPS، سرور اختصاصی یا سرویس ابری باشد.
مدیر کسب‌وکار لازم نیست متخصص سرور باشد.
اما باید بداند:
- ارائه‌دهنده زیرساخت چه کسی است؟
- حساب اصلی به نام چه کسی است؟
- اطلاعات ورود اصلی کجاست؟
- تمدید سرویس چگونه انجام می‌شود؟
- بکاپ‌ها کجا ذخیره می‌شوند؟
- در صورت خرابی سرور چه کسی می‌تواند اقدام کند؟
- آیا امکان انتقال سایت به سرور دیگر وجود دارد؟
چرا این موضوع مهم است؟
چون ممکن است شما صاحب دامنه باشید اما دسترسی مناسبی به زیرساخت نداشته باشید.
در چنین شرایطی، تغییر شرکت پشتیبان می‌تواند پیچیده شود.
یک پروژه حرفه‌ای باید طوری مدیریت شود که پشتیبانی یک تیم باعث حبس اطلاعات و وابستگی اجباری نشود.
کد سایت و فایل‌های پروژه متعلق به چه کسی است؟
اینجا یکی از مهم‌ترین تفاوت‌ها میان پروژه‌های حرفه‌ای و پروژه‌های بی‌مستند مشخص می‌شود.
باید بدانید:
کد سایت کجاست؟
آیا پروژه روی Git یا سیستم کنترل نسخه نگهداری می‌شود؟
آیا نسخه نهایی کد مشخص است؟
آیا مستندات فنی وجود دارد؟
آیا فایل‌های لازم برای اجرای پروژه در اختیار کارفرما یا تیم فنی جایگزین قرار می‌گیرد؟
البته موضوع حقوقی مالکیت کد، لایسنس نرم‌افزار، قالب، افزونه و قرارداد توسعه می‌تواند به شرایط قرارداد و قوانین مربوط بستگی داشته باشد و نباید صرفاً با عبارت «من پولش را داده‌ام، پس همه کدها متعلق به من است» نتیجه‌گیری کرد.
به همین دلیل، مالکیت و حق استفاده از کد باید در قرارداد به‌صورت شفاف مشخص شود.
دیتابیس؛ جایی که بخش بزرگی از اطلاعات سایت شما قرار دارد
یکی از دارایی‌هایی که معمولاً هنگام صحبت درباره مالکیت سایت فراموش می‌شود، دیتابیس یا پایگاه داده است.
ممکن است ظاهر سایت، تصاویر و صفحات آن کاملاً در دسترس شما باشد، اما اطلاعات اصلی فروشگاه، کاربران، سفارش‌ها، نوشته‌ها، تنظیمات و بسیاری از داده‌های دیگر در پایگاه داده ذخیره شده باشند.
بنابراین فقط داشتن فایل‌های ظاهری سایت کافی نیست.
برای یک وب‌سایت حرفه‌ای باید مشخص باشد:
- دیتابیس سایت روی چه سروری قرار دارد؟
- اطلاعات ورود به هاست یا سرور در اختیار چه کسی است؟
- بکاپ دیتابیس کجا نگهداری می‌شود؟
- آیا امکان دریافت نسخه خروجی از دیتابیس وجود دارد؟
- فرآیند بازیابی اطلاعات در صورت خرابی چگونه انجام می‌شود؟
- آیا اطلاعات سایت فقط روی یک سرور نگهداری می‌شود یا نسخه پشتیبان دیگری هم وجود دارد؟
یک نکته مهم
دسترسی به پنل سایت با دسترسی به زیرساخت سایت یکی نیست.
ممکن است شما بتوانید وارد وردپرس شوید و مطلب منتشر کنید، اما اگر به هاست، سرور یا نسخه پشتیبان دیتابیس دسترسی نداشته باشید، در شرایط بحرانی وابستگی شما همچنان باقی خواهد ماند.
حساب مدیریت سایت و CMS
اگر سایت شما با WordPress یا یک CMS دیگر ساخته شده است، باید حداقل یک حساب مدیریتی تحت کنترل خود کسب‌وکار داشته باشید.
در وردپرس، نقش‌های مختلفی مانند Administrator، Editor، Author و Contributor وجود دارد و هر نقش مجموعه متفاوتی از قابلیت‌ها را در اختیار کاربر قرار می‌دهد. در یک سایت تک‌نفره، Administrator بالاترین سطح مدیریتی را در اختیار دارد.
بنابراین اگر شرکت طراحی سایت به شما بگوید:
«هر زمان خواستید ما برایتان تغییر ایجاد می‌کنیم.»
این لزوماً به معنای داشتن کنترل واقعی سایت توسط شما نیست.
بهتر است مشخص باشد:
مدیر سایت چه کسی است؟
چه کسانی دسترسی مدیریتی دارند؟
آیا برای هر فرد حساب کاربری جداگانه ایجاد شده است؟
اگر یکی از اعضای تیم از پروژه خارج شود، آیا می‌توان دسترسی او را حذف کرد؟
این موضوع هم از نظر مالکیت و هم از نظر امنیت اهمیت دارد.
ایمیل سازمانی و حساب‌های مرتبط
گاهی یکی از مهم‌ترین مشکلات هنگام تغییر شرکت طراحی سایت، نه خود سایت، بلکه ایمیل‌های مرتبط با آن است.
برای مثال ممکن است ایمیل‌هایی مانند:
برای کسب‌وکار ساخته شده باشند اما اطلاعات مدیریت آنها در اختیار شخص یا شرکت دیگری باشد.
همچنین ممکن است ایمیل سازمانی برای بازیابی رمز عبور سرویس‌های دیگری استفاده شده باشد.
بنابراین هنگام تحویل سایت باید مشخص شود:
- ایمیل‌های سازمانی کجا مدیریت می‌شوند؟
- دامنه ایمیل در اختیار چه کسی است؟
- اطلاعات بازیابی حساب‌ها متعلق به چه کسی است؟
- ایمیل اصلی بازیابی سرویس‌ها چیست؟
- چه حساب‌هایی با این ایمیل‌ها ساخته شده‌اند؟
چرا این موضوع مهم است؟
اگر ایمیل بازیابی یک سرویس مهم در اختیار شخص دیگری باشد، حتی در صورت داشتن رمز عبور فعلی، کنترل بلندمدت آن حساب ممکن است برای کسب‌وکار شفاف نباشد.
Google Search Console؛ یکی از مهم‌ترین دسترسی‌های سئو
اگر سایت شما روی گوگل فعالیت جدی دارد، Google Search Console باید یکی از موارد اصلی در چک‌لیست مالکیت دیجیتال شما باشد.
در Search Console سطوح مختلف دسترسی وجود دارد. Owner کنترل کامل‌تری روی Property دارد و می‌تواند کاربران را مدیریت کند؛ Full User و Restricted User دسترسی‌های محدودتری دارند. گوگل همچنین تأکید می‌کند که برای یک Property باید حداقل یک Verified Owner وجود داشته باشد تا کاربران بتوانند به آن دسترسی داشته باشند.
بنابراین اگر شرکت سئو یا طراح سایت Search Console را برای شما راه‌اندازی کرده است، فقط پرسیدن اینکه:
«آیا سایت در سرچ کنسول ثبت شده؟»
کافی نیست.
باید بدانید:
مالک تأییدشده Property چه کسی است؟
حساب گوگل مالک متعلق به چه فرد یا مجموعه‌ای است؟
چه افرادی دسترسی دارند؟
آیا امکان حذف یا اضافه‌کردن کاربران توسط مالک وجود دارد؟
این موضوع به‌خصوص زمانی اهمیت پیدا می‌کند که بعداً بخواهید شرکت سئو یا طراح سایت خود را تغییر دهید.
Google Analytics و ابزارهای تحلیل
Google Analytics نیز باید تحت کنترل حسابی باشد که کسب‌وکار بتواند در بلندمدت به آن دسترسی داشته باشد.
در Google Analytics می‌توان کاربران را در سطح Account یا Property اضافه کرد و برای آنها نقش‌های متفاوتی مانند Administrator، Editor، Marketer، Analyst و Viewer تعریف کرد. سطح دسترسی نیز می‌تواند در طول زمان تغییر کند.
بنابراین بهتر است شرکت طراحی یا سئو به‌عنوان یک کاربر مجزا به Analytics اضافه شود، نه اینکه کل حساب اصلی صرفاً تحت کنترل پیمانکار باشد.
برای مثال:
حساب اصلی کسب‌وکار → مالک و کنترل اصلی
شرکت سئو → دسترسی موردنیاز برای کار
تحلیلگر → دسترسی متناسب با وظایف
این ساختار باعث می‌شود با پایان همکاری، بتوانید دسترسی پیمانکار را حذف کنید بدون اینکه کنترل حساب اصلی کسب‌وکار از بین برود.
درگاه پرداخت و سرویس‌های مالی
اگر سایت شما فروشگاهی است، درگاه پرداخت یکی از حساس‌ترین بخش‌های پروژه محسوب می‌شود.
در اینجا باید مشخص باشد:
- درگاه به نام چه شخص یا شرکتی ثبت شده است؟
- حساب بانکی مقصد متعلق به چه کسی است؟
- اطلاعات ورود به پنل درگاه در اختیار چه کسی است؟
- شماره تماس و ایمیل بازیابی متعلق به چه کسی است؟
- کلیدها یا اطلاعات اتصال درگاه چگونه مدیریت می‌شوند؟
- در صورت تغییر شرکت طراحی سایت، فرآیند انتقال چگونه انجام خواهد شد؟
در این بخش بهتر است اطلاعات حساس پرداخت به‌صورت عمومی یا در اختیار افراد غیرمرتبط نگهداری نشود.
هدف این نیست که همه اعضای تیم به همه اطلاعات دسترسی داشته باشند؛ هدف این است که مالک کسب‌وکار بتواند کنترل قانونی و عملیاتی سرویس را حفظ کند.
APIها و سرویس‌های متصل به سایت
وب‌سایت‌های مدرن معمولاً فقط به یک هاست و یک CMS محدود نیستند.
ممکن است سایت شما به سرویس‌هایی مانند:
- سامانه پیامکی
- درگاه پرداخت
- سرویس ارسال ایمیل
- CRM
- نرم‌افزار حسابداری
- سرویس حمل‌ونقل
- نقشه و موقعیت مکانی
- سرویس‌های تحلیل داده
- سرویس‌های هوش مصنوعی
- سیستم مدیریت مشتریان
متصل باشد.
در چنین شرایطی باید مشخص شود هر اتصال با چه حسابی ساخته شده و مالک آن حساب چه کسی است.
چرا API مهم است؟
گاهی بعد از تغییر شرکت طراحی سایت، خود سایت در دسترس است اما یکی از قابلیت‌های آن کار نمی‌کند؛ چون API Key، توکن یا حساب سرویس خارجی در اختیار تیم قبلی بوده است.
بنابراین تحویل پروژه باید شامل مستندات سرویس‌های متصل نیز باشد.
البته اطلاعات محرمانه مانند کلیدهای خصوصی نباید بی‌دلیل در فایل‌های عمومی یا پیام‌های معمولی نگهداری شوند؛ بهتر است مدیریت آنها با روش امن و قابل کنترل انجام شود.
فایل‌های طراحی، UI/UX و دارایی‌های گرافیکی
مالکیت سایت فقط به کد محدود نمی‌شود.
در بسیاری از پروژه‌ها فایل‌های دیگری نیز وجود دارند، مانند:
- فایل‌های طراحی UI/UX
- لوگو
- تصاویر اختصاصی
- فایل‌های گرافیکی
- آیکون‌ها
- فایل‌های طراحی صفحات
- وکتورها
- فایل‌های تبلیغاتی
- بنرها
- فایل‌های ویرایش‌پذیر طراحی
اگر قرار است این موارد بخشی از تحویل پروژه باشند، بهتر است در قرارداد و فرآیند تحویل دقیقاً مشخص شوند.
برای مثال:
«فایل نهایی طراحی صفحات سایت و دارایی‌های گرافیکی پروژه در پایان پروژه تحویل خواهد شد.»
این جمله بسیار شفاف‌تر از این است که صرفاً گفته شود:
«سایت تحویل مشتری می‌شود.»
بکاپ سایت واقعاً دست چه کسی است؟
یکی از مهم‌ترین سؤال‌هایی که مدیر سایت باید بپرسد این است:
اگر فردا سایت از کار بیفتد، آخرین نسخه سالم آن کجاست؟
بکاپ فقط یک گزینه اضافی نیست.
برای یک سایت حرفه‌ای باید مشخص باشد:
- بکاپ هر چند وقت یک‌بار گرفته می‌شود؟
- بکاپ شامل چه چیزهایی است؟
- فایل‌های سایت در بکاپ وجود دارند؟
- دیتابیس نیز پشتیبان‌گیری می‌شود؟
- نسخه‌های قبلی تا چه مدت نگهداری می‌شوند؟
- بکاپ روی همان سرور قرار دارد یا محل دیگری؟
- چه کسی امکان بازیابی بکاپ را دارد؟
- آخرین بار چه زمانی بازیابی بکاپ آزمایش شده است؟
یک اشتباه رایج
گاهی گفته می‌شود:
«نگران نباشید، بکاپ داریم.»
اما وقتی سؤال می‌کنید:
«کجاست؟»
پاسخ مشخصی وجود ندارد.
بکاپی که مالک آن، محل نگهداری آن و روش بازیابی آن مشخص نیست، یک برنامه پشتیبان‌گیری شفاف محسوب نمی‌شود.
چرا استفاده از یک حساب مشترک برای همه دسترسی‌ها خطرناک است؟
یکی از اشتباهات رایج این است که تمام سرویس‌ها با یک ایمیل و یک رمز عبور مشترک ساخته شوند.
مثلاً:
Gmail اصلی → دامنه → هاست → Search Console → Analytics → وردپرس → سرویس پیامکی
و چند نفر هم همان رمز را داشته باشند.
این روش شاید در ابتدا ساده به نظر برسد، اما در بلندمدت مدیریت دسترسی را بسیار دشوار می‌کند.
اگر یکی از افراد پروژه خارج شود، چه اتفاقی می‌افتد؟
آیا باید رمز تمام سرویس‌ها تغییر کند؟
اگر رمز در چند جای دیگر نیز استفاده شده باشد چه؟
آیا مشخص است چه کسی به چه سرویسی دسترسی داشته است؟
راهکار حرفه‌ای‌تر این است که تا حد امکان:
مالکیت حساب اصلی نزد کسب‌وکار باشد و دسترسی افراد و شرکت‌ها به‌صورت جداگانه و بر اساس نقش آنها مدیریت شود.
برای سرویس‌هایی مانند Search Console و Analytics نیز خود سرویس امکان مدیریت کاربران و سطوح دسترسی را فراهم می‌کند.
تفاوت «دسترسی داشتن» با «مالک بودن»
این یکی از مهم‌ترین بخش‌های کل مقاله است.
فرض کنید طراح سایت به شما یک نام کاربری و رمز عبور داده و شما می‌توانید وارد پنل شوید.
آیا این یعنی مالکیت کامل سایت با شماست؟
لزوماً نه.
چون ممکن است:
- دامنه در حساب دیگری باشد.
- هاست متعلق به حساب دیگری باشد.
- بکاپ در اختیار شرکت دیگری باشد.
- Search Console مالک دیگری داشته باشد.
- Analytics تحت یک حساب دیگر ایجاد شده باشد.
- کد پروژه در مخزن خصوصی شخص دیگری باشد.
- سرویس‌های API با حساب پیمانکار ساخته شده باشند.
- قرارداد درباره حقوق استفاده یا انتقال کد سکوت کرده باشد.
پس باید بین دو مفهوم تفاوت قائل شویم:
دسترسی
یعنی شما در حال حاضر می‌توانید وارد یک سرویس شوید و کاری انجام دهید.
مالکیت یا کنترل
یعنی ساختار حساب، قرارداد، اطلاعات ثبت‌شده و دسترسی‌های مدیریتی به شکلی تنظیم شده که کسب‌وکار بتواند در بلندمدت آن دارایی را کنترل و در صورت نیاز منتقل کند.
این دو مفهوم همیشه یکی نیستند.
دسترسی طراح سایت باید چگونه مدیریت شود؟
اینکه طراح سایت دسترسی داشته باشد، ذاتاً مشکل نیست.
اتفاقاً برای پشتیبانی و توسعه سایت، معمولاً به دسترسی فنی نیاز دارد.
مسئله اصلی این است که دسترسی طراح با مالکیت کسب‌وکار اشتباه گرفته نشود.
ساختار مناسب می‌تواند چیزی شبیه این باشد:
| نوع دسترسی | کسب‌وکار | طراح/پشتیبان |
| دامنه | کنترل اصلی | در صورت نیاز |
| هاست | کنترل اصلی | دسترسی فنی |
| وردپرس | Administrator | نقش موردنیاز |
| Search Console | Owner | Full User در صورت نیاز |
| Analytics | Administrator | نقش موردنیاز |
| بکاپ | دسترسی/کنترل اصلی | دسترسی فنی در صورت نیاز |
| APIها | مالک حساب | دسترسی فنی لازم |
| فایل‌های پروژه | نسخه اصلی | دسترسی توسعه |
این مدل به این معنی نیست که همه پروژه‌ها باید دقیقاً با همین ساختار اجرا شوند؛ بلکه اصل مهم این است که دسترسی‌ها بر اساس نیاز کاری تعریف شوند و کنترل دارایی‌های اصلی از کسب‌وکار خارج نشود.
وقتی یک کارمند یا پیمانکار از پروژه خارج می‌شود چه کنیم؟
مدیریت دسترسی فقط برای شرکت طراحی سایت نیست.
اگر یک کارمند، فریلنسر، مدیر محتوا، سئوکار یا توسعه‌دهنده از پروژه خارج شد، باید دسترسی‌های او بررسی شود.
یک فرآیند ساده می‌تواند شامل این موارد باشد:
مرحله اول: فهرست دسترسی‌ها
مشخص کنید فرد به چه سرویس‌هایی دسترسی داشته است.
مرحله دوم: حذف دسترسی‌های غیرضروری
حساب‌های کاربری مربوط به فرد را حذف یا سطح دسترسی آنها را تغییر دهید.
مرحله سوم: بررسی حساب‌های مشترک
اگر رمز مشترکی وجود داشته، رمز آن سرویس تغییر کند.
مرحله چهارم: بررسی روش‌های بازیابی
ایمیل، شماره تماس یا روش بازیابی حساب‌ها بررسی شود.
مرحله پنجم: بررسی کلیدهای فنی
در صورت لزوم API Key، Token یا سایر اطلاعات دسترسی فنی که دیگر نباید فعال باشند، مدیریت یا جایگزین شوند.
هدف این است که بعد از خروج یک فرد، دسترسی او نیز از پروژه خارج شود.
اگر طراح سایت همکاری را متوقف کرد چه چیزهایی باید در اختیار شما باشد؟
حالا به سؤال اصلی مقاله برگردیم.
فرض کنید طراح سایت شما از فردا دیگر پاسخ‌گو نیست.
آیا سایت شما باید متوقف شود؟
اگر مالکیت و دسترسی‌ها از ابتدا درست طراحی شده باشند، نباید ادامه فعالیت کسب‌وکار صرفاً به حضور یک فرد وابسته باشد.
حداقل باید بتوانید اطلاعات زیر را در اختیار داشته باشید:
اطلاعات دامنه
- نام دامنه
- شرکت ثبت‌کننده
- حساب مالک
- ایمیل بازیابی
- اطلاعات تمدید
- اطلاعات DNS
اطلاعات هاست یا سرور
- شرکت ارائه‌دهنده
- حساب کاربری
- اطلاعات تمدید
- مشخصات سرویس
- اطلاعات لازم برای مدیریت یا انتقال
اطلاعات سایت
- CMS
- حساب‌های مدیریتی
- نسخه PHP و سایر نیازمندی‌های فنی در صورت مرتبط بودن
- افزونه‌ها و قالب‌ها
- مستندات فنی
اطلاعات پروژه
- کد منبع یا فایل‌های مورد توافق
- فایل‌های طراحی
- مستندات
- نسخه‌های پروژه
اطلاعات داده
- دیتابیس
- بکاپ‌ها
- روش بازیابی
ابزارهای گوگل
- Search Console
- Analytics
- Google Business Profile در صورت استفاده
- سایر سرویس‌های مرتبط
سرویس‌های جانبی
- درگاه
- پیامک
- ایمیل
- APIها
- CRM
- سرویس‌های خارجی
اگر بخش بزرگی از این فهرست برای شما نامشخص است، احتمالاً لازم است وضعیت مالکیت و دسترسی سایت خود را یک‌بار جدی بررسی کنید.
هنگام انتقال سایت چه اطلاعاتی باید تحویل داده شود؟
تحویل سایت نباید فقط به یک پیام ساده مثل:
«سایت آماده است.»
خلاصه شود.
یک پروژه حرفه‌ای بهتر است فرآیند تحویل مشخص داشته باشد.
چک‌لیست پیشنهادی تحویل سایت
| مورد | وضعیت |
| دامنه و حساب ثبت‌کننده | ☐ |
| اطلاعات DNS | ☐ |
| هاست یا سرور | ☐ |
| اطلاعات CMS | ☐ |
| حساب‌های مدیریتی | ☐ |
| دیتابیس | ☐ |
| فایل‌های سایت | ☐ |
| کد پروژه در صورت توافق | ☐ |
| بکاپ نهایی | ☐ |
| فایل‌های طراحی | ☐ |
| Search Console | ☐ |
| Google Analytics | ☐ |
| درگاه پرداخت | ☐ |
| سرویس پیامکی | ☐ |
| APIها و سرویس‌های خارجی | ☐ |
| مستندات فنی | ☐ |
| اطلاعات تمدید سرویس‌ها | ☐ |
این فهرست می‌تواند برای هر پروژه با توجه به نوع سایت تغییر کند.
یک سایت شرکتی ساده با یک فروشگاه اینترنتی بزرگ یا یک سامانه اختصاصی طبیعتاً نیازهای یکسانی ندارد.
قرارداد طراحی سایت باید درباره مالکیت چه چیزهایی مشخص کند؟
یکی از بهترین راه‌های جلوگیری از اختلاف، مشخص‌کردن موضوعات مهم قبل از شروع پروژه است.
قرارداد طراحی سایت بهتر است درباره موارد مرتبط با پروژه شفاف باشد، از جمله:
۱. دامنه
مشخص شود دامنه به نام چه شخص یا مجموعه‌ای ثبت می‌شود و کنترل حساب ثبت دامنه چگونه خواهد بود.
۲. هاست و زیرساخت
مشخص شود سرویس به نام چه کسی تهیه می‌شود و اطلاعات مدیریت آن چگونه تحویل خواهد شد.
۳. کد و فایل‌های پروژه
باید دقیقاً مشخص شود درباره کد اختصاصی، قالب، افزونه، فایل‌های طراحی و سایر اجزای پروژه چه حقوقی به مشتری داده می‌شود.
این بخش اهمیت زیادی دارد؛ زیرا نمی‌توان صرفاً از روی پرداخت هزینه طراحی نتیجه گرفت که تمام حقوق قانونی مربوط به هر قطعه کد، قالب، افزونه یا نرم‌افزار ثالث خودکار منتقل شده است.
۴. حساب‌های سرویس‌های خارجی
مشخص شود حساب‌های مورد استفاده برای سرویس‌هایی مانند Analytics، Search Console، پیامک، API و سایر خدمات چگونه ایجاد و مدیریت می‌شوند.
۵. بکاپ
تعداد یا برنامه پشتیبان‌گیری و نحوه تحویل یا دسترسی به نسخه‌های پشتیبان، در صورت توافق، مشخص شود.
۶. فرآیند تحویل
مشخص شود پروژه در پایان همکاری دقیقاً با چه مواردی تحویل داده می‌شود.
۷. پشتیبانی
مدت، محدوده و شرایط پشتیبانی نیز بهتر است از ابتدا مشخص باشد.
یک نکته بسیار مهم درباره «مالکیت»
در این مقاله بارها از عبارت «مالکیت سایت» استفاده کردیم، اما در عمل یک وب‌سایت مجموعه‌ای از دارایی‌های متفاوت است.
ممکن است دامنه، کد اختصاصی، قالب، افزونه، محتوای متنی، تصاویر، دیتابیس، حساب‌های آنلاین و سرویس‌های ثالث، وضعیت حقوقی یکسانی نداشته باشند.
بنابراین بهترین رویکرد این نیست که فقط بپرسیم:
«سایت مال چه کسی است؟»
بلکه باید سؤال را دقیق‌تر کنیم:
«مالک یا کنترل‌کننده هر یک از دارایی‌های اصلی سایت چه کسی است و در صورت پایان همکاری، چگونه می‌توان آن را مدیریت یا منتقل کرد؟»
این نگاه، بسیار دقیق‌تر و حرفه‌ای‌تر است.
چک‌لیست مالکیت سایت برای مدیران کسب‌وکار
اگر بخواهیم تمام مطالب این مقاله را به یک چک‌لیست ساده تبدیل کنیم، مدیر یک کسب‌وکار باید بتواند برای موارد زیر پاسخ مشخصی داشته باشد:
| دارایی یا دسترسی | آیا تحت کنترل کسب‌وکار است؟ |
| دامنه | ☐ بله / ☐ خیر |
| حساب ثبت دامنه | ☐ بله / ☐ خیر |
| ایمیل بازیابی دامنه | ☐ بله / ☐ خیر |
| DNS | ☐ بله / ☐ خیر |
| هاست یا سرور | ☐ بله / ☐ خیر |
| اطلاعات تمدید هاست | ☐ بله / ☐ خیر |
| حساب مدیریت سایت | ☐ بله / ☐ خیر |
| دیتابیس | ☐ بله / ☐ خیر |
| فایل‌های سایت | ☐ بله / ☐ خیر |
| کد پروژه | ☐ بله / ☐ خیر |
| بکاپ | ☐ بله / ☐ خیر |
| فایل‌های طراحی | ☐ بله / ☐ خیر |
| Search Console | ☐ بله / ☐ خیر |
| Google Analytics | ☐ بله / ☐ خیر |
| درگاه پرداخت | ☐ بله / ☐ خیر |
| سرویس پیامکی | ☐ بله / ☐ خیر |
| APIها | ☐ بله / ☐ خیر |
| ایمیل سازمانی | ☐ بله / ☐ خیر |
| اطلاعات تمدید سرویس‌ها | ☐ بله / ☐ خیر |
| مستندات فنی | ☐ بله / ☐ خیر |
اگر برای چند مورد مهم پاسخ شما «خیر» یا «نمی‌دانم» است، بهتر است قبل از وقوع یک مشکل واقعی، وضعیت آنها را بررسی کنید.
اشتباهات رایج در مالکیت و مدیریت سایت
بسیاری از مشکلات مالکیت سایت نه به دلیل یک اتفاق پیچیده، بلکه به دلیل چند اشتباه ساده ایجاد می‌شوند.
اشتباه اول: دامنه به نام شخص دیگری است
ممکن است طراحی سایت را یک شرکت انجام داده باشد اما دامنه با حساب فرد دیگری ثبت شده باشد.
در چنین شرایطی باید وضعیت ثبت دامنه و حساب ثبت‌کننده بررسی شود. ICANN نیز برای دارنده ثبت‌شده دامنه، حقوق و فرآیندهای مشخصی درباره مدیریت و انتقال دامنه در نظر گرفته است.
اشتباه دوم: همه رمزها دست طراح سایت است
اگر تمام حساب‌ها فقط با یک ایمیل و رمز متعلق به طراح ایجاد شده باشند، کسب‌وکار در عمل به او وابسته می‌شود.
اشتباه سوم: بکاپ وجود دارد اما محل آن مشخص نیست
گفتن «بکاپ داریم» کافی نیست.
باید بدانید بکاپ کجاست، شامل چه اطلاعاتی است و چگونه بازیابی می‌شود.
اشتباه چهارم: Search Console به حساب شخصی سئوکار وابسته است
در این حالت هنگام تغییر شرکت سئو ممکن است مدیریت دسترسی‌ها پیچیده شود.
اشتباه پنجم: حساب‌ها با ایمیل شخصی کارمند ساخته شده‌اند
اگر فردی از شرکت خارج شود، ممکن است بازیابی حساب‌های مهم دشوار شود.
اشتباه ششم: قرارداد درباره تحویل پروژه سکوت کرده است
عبارت «طراحی سایت اختصاصی» به‌تنهایی مشخص نمی‌کند چه چیزهایی در پایان همکاری باید تحویل داده شوند.
اشتباه هفتم: مالکیت و دسترسی با هم اشتباه گرفته می‌شوند
اینکه یک شخص بتواند وارد پنل شود، لزوماً به این معنی نیست که ساختار مالکیت و کنترل دارایی به شکل مناسبی تنظیم شده است.
آیا شرکت طراحی سایت باید همیشه دسترسی مدیر سایت را داشته باشد؟
خیر؛ مسئله اصلی اصل دسترسی نیست، بلکه نوع و سطح دسترسی است.
یک شرکت طراحی یا پشتیبانی ممکن است برای انجام وظایف خود به دسترسی فنی نیاز داشته باشد.
اما بهتر است این دسترسی:
- مشخص باشد؛
- متناسب با وظیفه باشد؛
- قابل لغو باشد؛
- به حساب شخصی وابسته نباشد؛
- و از مالکیت اصلی کسب‌وکار جدا باشد.
برای مثال، اگر یک توسعه‌دهنده فقط وظیفه توسعه افزونه خاصی را دارد، لزوماً نباید تمام اطلاعات حساب‌های دیگر کسب‌وکار را در اختیار داشته باشد.
این اصل را می‌توان با یک جمله ساده خلاصه کرد:
هر فرد باید به اندازه‌ای دسترسی داشته باشد که بتواند وظیفه خود را انجام دهد؛ نه بیشتر.
مالکیت سایت و امنیت چه ارتباطی با هم دارند؟
مالکیت صحیح فقط یک مسئله اداری نیست؛ مستقیماً با امنیت نیز ارتباط دارد.
فرض کنید:
- رمز عبور دامنه در اختیار چند نفر است؛
- حساب هاست با ایمیل یک پیمانکار ساخته شده؛
- همه اعضای تیم از یک حساب وردپرس استفاده می‌کنند؛
- بکاپ فقط روی همان سرور قرار دارد؛
- و حساب‌های مهم با شماره یا ایمیل فردی خارج از شرکت بازیابی می‌شوند.
در چنین شرایطی حتی اگر سایت امروز بدون مشکل کار کند، مدیریت ریسک آن ساختار شفاف نیست.
ساختار امن‌تر
در یک ساختار مناسب بهتر است:
مالک اصلی → کسب‌وکار
کاربر اجرایی → کارمند یا پیمانکار
دسترسی → متناسب با وظیفه
بکاپ → محل مستقل و قابل کنترل
بازیابی → تحت کنترل کسب‌وکار
این تفکیک باعث می‌شود خروج یک فرد، به معنی از دست رفتن کل زیرساخت نباشد.
مالکیت سایت و سئو؛ چه چیزی ممکن است از دست برود؟
ممکن است در نگاه اول تصور کنیم مالکیت سایت هیچ ارتباطی با سئو ندارد.
اما در عمل، بسیاری از دارایی‌های مهم سئو به حساب‌ها و ابزارهای دیجیتال وابسته هستند.
برای مثال:
- Google Search Console
- Google Analytics
- داده‌های عملکرد سایت
- تنظیمات فنی
- گزارش‌های ایندکس
- اطلاعات خطاها
- داده‌های جست‌وجو
- فایل‌های سایت
- ساختار URL
- بکاپ نسخه‌های قبلی
Search Console به مدیران اجازه می‌دهد اطلاعات عملکرد سایت در جست‌وجوی گوگل و برخی ابزارهای مرتبط را مشاهده و مدیریت کنند؛ به همین دلیل کنترل درست دسترسی آن برای مدیریت بلندمدت سایت اهمیت دارد.
حالا تصور کنید شرکت سئو تغییر کند اما:
مالکیت Search Console مشخص نباشد.
یا:
داده‌های تحلیلی فقط در حساب شرکت قبلی باقی مانده باشد.
در چنین شرایطی، تغییر پیمانکار می‌تواند باعث ایجاد اصطکاک و از دست رفتن بخشی از تداوم داده‌ها و دسترسی‌های مدیریتی شود.
بنابراین مالکیت و مدیریت دسترسی باید از همان ابتدای پروژه در استراتژی سئو نیز دیده شود.
قبل از تغییر شرکت طراحی سایت چه کارهایی انجام دهیم؟
اگر تصمیم گرفته‌اید شرکت طراحی یا پشتیبان سایت را تغییر دهید، بهتر است ابتدا اطلاعات موجود را جمع‌آوری کنید.
مرحله اول: فهرست دارایی‌ها
دامنه، هاست، CMS، دیتابیس، بکاپ، Search Console، Analytics، درگاه و سایر سرویس‌ها را فهرست کنید.
مرحله دوم: بررسی مالکیت
برای هر مورد مشخص کنید:
حساب متعلق به چه کسی است؟
ایمیل بازیابی چیست؟
چه کسانی دسترسی دارند؟
مرحله سوم: تهیه بکاپ
قبل از هر تغییر مهم، از سایت و دیتابیس نسخه پشتیبان تهیه و محل نگهداری آن را مشخص کنید.
مرحله چهارم: بررسی سرویس‌های جانبی
APIها، پیامک، ایمیل، درگاه، CRM و سایر اتصال‌ها را بررسی کنید.
مرحله پنجم: بررسی قرارداد
قرارداد و توافق‌های قبلی را بررسی کنید تا مشخص باشد چه مواردی باید تحویل داده شوند.
مرحله ششم: ایجاد دسترسی برای تیم جدید
پس از مشخص‌شدن ساختار، دسترسی موردنیاز شرکت جدید را ایجاد کنید.
مرحله هفتم: حذف دسترسی‌های قدیمی
بعد از اطمینان از اینکه همه سرویس‌ها در اختیار کسب‌وکار و تیم جدید قرار گرفته‌اند، دسترسی‌های غیرضروری تیم قبلی را حذف یا محدود کنید.
اگر همین امروز بخواهیم مالکیت سایت را بررسی کنیم از کجا شروع کنیم؟
لازم نیست از همان ابتدا وارد جزئیات فنی پیچیده شوید.
یک بررسی ساده را با این پنج سؤال شروع کنید:
سؤال اول
دامنه سایت به نام چه کسی است و چه کسی به حساب ثبت دامنه دسترسی دارد؟
سؤال دوم
هاست یا سرور سایت در چه حسابی قرار دارد؟
سؤال سوم
آیا یک حساب مدیریتی مستقل و تحت کنترل کسب‌وکار برای سایت وجود دارد؟
سؤال چهارم
مالک و مدیر اصلی Search Console و Analytics چه کسی است؟
سؤال پنجم
اگر طراح سایت از فردا پاسخ‌گو نباشد، آیا می‌توانیم سایت را مدیریت، بکاپ را بازیابی و سرویس‌های اصلی را کنترل کنیم؟
اگر جواب هر پنج سؤال روشن است، وضعیت شما قابل بررسی و مدیریت است.
اگر پاسخ بعضی از آنها «نمی‌دانم» است، همان موارد بهترین نقطه شروع برای بررسی بیشتر هستند.
سوالات متداول درباره مالکیت سایت
آیا پرداخت هزینه طراحی سایت یعنی سایت کاملاً متعلق به مشتری است؟
نه لزوماً.
موضوع مالکیت باید با توجه به قرارداد، نوع دارایی و حقوق مربوط به هر جزء بررسی شود.
دامنه، کد اختصاصی، قالب، افزونه، تصاویر، محتوا و سرویس‌های ثالث ممکن است شرایط متفاوتی داشته باشند.
به همین دلیل بهتر است قرارداد به‌صورت مشخص درباره موارد موردنظر طرفین صحبت کند.
آیا دامنه باید به نام شرکت باشد؟
برای کسب‌وکارها معمولاً منطقی است که کنترل دامنه و اطلاعات ثبت‌شده آن تحت کنترل خود کسب‌وکار باشد.
جزئیات حقوقی و الزامات ثبت دامنه به نوع دامنه و مرجع ثبت آن بستگی دارد. در دامنه‌های تحت سیاست‌های ICANN، Registered Name Holder نقش مشخصی در مدیریت و انتقال دامنه دارد.
آیا شرکت طراحی سایت باید رمز اصلی سایت را داشته باشد؟
ضرورتی ندارد که همه افراد از یک رمز مشترک استفاده کنند.
بهتر است هر فرد حساب مناسب خودش را داشته باشد و سطح دسترسی متناسب با وظیفه تعیین شود.
اگر طراح سایت رمز سایت را به من ندهد چه کار کنم؟
اول باید مشخص شود منظور از «رمز سایت» دقیقاً چیست.
آیا منظور:
- وردپرس است؟
- هاست است؟
- دامنه است؟
- دیتابیس است؟
- Search Console است؟
- حساب سرویس دیگری است؟
سپس باید قرارداد، ساختار حساب و مالکیت آن سرویس بررسی شود.
آیا می‌توانم شرکت طراحی سایت را عوض کنم؟
در بسیاری از پروژه‌ها بله، اما سه موضوع باید بررسی شود:
قرارداد
مالکیت و دسترسی دارایی‌ها
امکان فنی انتقال پروژه
قبل از تغییر شرکت، بهتر است فهرست کاملی از دارایی‌ها و دسترسی‌ها تهیه شود.
اگر طراح سایت ناپدید شود، آیا سایت از بین می‌رود؟
لزوماً نه.
اگر دامنه، هاست، فایل‌ها، دیتابیس، بکاپ‌ها و حساب‌های اصلی تحت کنترل کسب‌وکار باشند، نبودن طراح به‌تنهایی نباید باعث از بین رفتن سایت شود.
مشکل زمانی جدی‌تر می‌شود که بخش‌های اصلی پروژه فقط تحت کنترل یک فرد یا شرکت باشند.
آیا باید کد سایت را از طراح سایت تحویل بگیرم؟
این موضوع به نوع پروژه، قرارداد، فناوری مورد استفاده و حقوق مربوط به کد بستگی دارد.
در پروژه‌های اختصاصی، بهتر است قرارداد از ابتدا درباره دسترسی به کد، تحویل فایل‌ها، حقوق استفاده و شرایط انتقال شفاف باشد.
آیا داشتن بکاپ به معنی مالکیت سایت است؟
خیر.
بکاپ فقط یکی از اجزای مدیریت و تداوم کسب‌وکار است.
ممکن است شما یک نسخه بکاپ داشته باشید اما دامنه یا حساب‌های اصلی همچنان در اختیار شخص دیگری باشند.
برای سایت وردپرسی چه دسترسی‌هایی اهمیت بیشتری دارند؟
حداقل باید وضعیت این موارد مشخص باشد:
- حساب مدیریتی وردپرس
- هاست
- دامنه
- دیتابیس
- بکاپ
- Search Console
- Analytics
- سرویس‌های جانبی
البته بسته به ساختار سایت، موارد دیگری نیز ممکن است وجود داشته باشد.
آیا مالکیت سایت فقط مربوط به شرکت‌های بزرگ است؟
خیر.
حتی یک سایت شرکتی کوچک نیز ممکن است شامل دامنه، هاست، ایمیل سازمانی، اطلاعات مشتریان، محتوای اختصاصی و حساب‌های مختلف باشد.
هرچه سایت برای کسب‌وکار مهم‌تر باشد، مدیریت صحیح این دارایی‌ها اهمیت بیشتری پیدا می‌کند.
جمع‌بندی؛ سایت شما باید برای کسب‌وکار باشد، نه وابسته به یک فرد
یک وب‌سایت فقط چند صفحه اینترنتی نیست.
برای بسیاری از کسب‌وکارها، سایت شامل مجموعه‌ای از دارایی‌های دیجیتال است:
دامنه
هاست
کد
دیتابیس
محتوا
حساب‌های مدیریتی
ایمیل سازمانی
ابزارهای تحلیل
داده‌های سئو
درگاه پرداخت
APIها
بکاپ‌ها
اگر همه این موارد به شکلی شفاف مدیریت شوند، تغییر یک طراح، توسعه‌دهنده یا شرکت پشتیبان لزوماً به یک بحران تبدیل نمی‌شود.
اما اگر کسب‌وکار حتی نداند دامنه‌اش کجاست، بکاپش کجاست یا چه کسی مالک حساب‌های اصلی است، مشکل فقط «طراح سایت» نیست؛ ساختار مالکیت و مدیریت دارایی‌های دیجیتال نیاز به بازبینی دارد.
بهترین زمان برای حل این مشکل، زمانی نیست که طراح سایت ناپدید شده است.
بهترین زمان، قبل از شروع پروژه و در زمان طراحی ساختار سایت است.
یک همکاری حرفه‌ای باید به شکلی شکل بگیرد که شرکت طراحی سایت در کنار کسب‌وکار قرار بگیرد، نه اینکه کسب‌وکار برای ادامه فعالیت خود به یک فرد خاص وابسته شود.
طراحی سایت حرفه‌ای یعنی ساخت یک دارایی قابل مدیریت
طراحی یک سایت خوب فقط به ظاهر زیبا، سرعت مناسب یا امکانات فنی محدود نمی‌شود.
یک وب‌سایت حرفه‌ای باید از ابتدا با نگاه بلندمدت طراحی شود:
- ساختار فنی مشخص داشته باشد؛
- دسترسی‌ها قابل مدیریت باشند؛
- اطلاعات و داده‌ها قابل پشتیبان‌گیری باشند؛
- حساب‌های اصلی تحت کنترل کسب‌وکار باشند؛
- وضعیت مالکیت دارایی‌ها روشن باشد؛
- امکان توسعه و انتقال پروژه وجود داشته باشد؛
- و در صورت تغییر تیم، کسب‌وکار بتواند مسیر خود را ادامه دهد.
در تارنما پیشروآرا نگاه به طراحی سایت فقط ساخت یک ظاهر اینترنتی نیست؛ هدف، ایجاد یک زیرساخت دیجیتال متناسب با نیاز کسب‌وکار است؛ زیرساختی که بتواند در کنار طراحی، توسعه، سئو و نیازهای آینده مجموعه نیز رشد کند.
اگر قصد راه‌اندازی سایت جدید دارید یا می‌خواهید وضعیت سایت فعلی خود را از نظر مالکیت، دسترسی، امنیت، زیرساخت و قابلیت توسعه بررسی کنید، بهتر است قبل از هر تصمیم، ابتدا وضعیت فعلی دارایی‌های دیجیتال کسب‌وکارتان مشخص شود.
سایت شما یک دارایی برای کسب‌وکار شماست؛ پس کنترل آن نیز باید در اختیار کسب‌وکار شما باشد.
نتیجه نهایی مقاله در یک نگاه
دامنه را بشناسید.
هاست را بشناسید.
حساب‌های اصلی را تحت کنترل داشته باشید.
بکاپ مستقل داشته باشید.
دسترسی‌ها را تفکیک کنید.
قرارداد شفاف داشته باشید.
و مهم‌تر از همه، مالکیت را با صرفاً «رمز ورود داشتن» اشتباه نگیرید.
زیرا روزی که همکاری با طراح سایت تمام می‌شود، تازه مشخص خواهد شد که آیا واقعاً صاحب یک وب‌سایت هستید یا فقط تا زمانی به آن دسترسی داشته‌اید که شخص دیگری کنار شما بوده است.
دیدگاه خود را ثبت کنید...
آدرس ایمیل شما با توجه به قوانین حریم خصوصی منتشر نمی شود.