یک عصر با سایتساز صفحهای زیبا میسازید؛ دو ماه بعد میفهمید فرم سرنخ گاهی پیام را نمیفرستد، دامنه در حساب پیمانکار است، نسخه موبایل در اینترنت اپراتور کند میشود و خروجی گرفتن از سفارشها با نیاز مالی شما سازگار نیست. مشکل «سایتساز» نیست؛ مسئله این است که ظاهر را قبل از مالکیت، فرایند، محدودیت و راه خروج انتخاب کردهاید.
ساخت سایت حرفهای با سایتساز ممکن است، به شرطی که حرفهایبودن را با تعداد انیمیشن یا قالب Premium نسنجید. سایت حرفهای باید کار مشخصی را برای مخاطب انجام دهد، سریع و قابلاستفاده باشد، شواهد اعتماد ارائه کند، داده و دامنهاش تحت کنترل کسبوکار بماند و در صورت رشد یا قطع همکاری، مسیر مهاجرت داشته باشد.
سایتساز چیست؟
Website Builder پلتفرمی است که ساخت صفحه، مدیریت محتوا، قالب، میزبانی یا بخشی از قابلیتهای سایت را با رابط آماده ارائه میکند. بعضی کاملاً SaaS و بستهاند؛ بعضی روی CMS متنباز با Page Builder اجرا میشوند؛ بعضی No-code/Low-code هستند و خروجی Front-end یا Integration میدهند. این گروهها هزینه، کنترل و مسئولیت یکسان ندارند.
| مدل | چه چیزی میخرید؟ | مزیت اصلی | ریسک اصلی |
|---|---|---|---|
| SaaS یکپارچه | Editor، Hosting، Update و Support | راهاندازی و عملیات سادهتر | Lock-in و محدودیت Integration/Export |
| CMS خودمیزبان + Builder | نرمافزار، قالب/افزونه و Hosting جدا | کنترل و اکوسیستم بیشتر | مسئولیت امنیت، Update و سازگاری |
| No-code/Low-code | UI builder، CMS و Workflow/API | Prototype و تجربه سفارشیتر | پیچیدگی عملیاتی پنهان و محدودیت Runtime |
| توسعه اختصاصی | کد و معماری متناسب | کنترل عمیق برای نیاز متمایز | هزینه ساخت، نگهداری و تیم |
مرزها مطلق نیستند؛ یک SaaS میتواند API قوی داشته باشد و یک CMS خودمیزبان با قالب وابسته، عملاً Lock-in بیشتری بسازد. محصول را با نسخه، پلن و قرارداد روز ارزیابی کنید، نه با برچسب کلی.
وبسایت حرفهای چه ویژگیهایی دارد؟
حرفهایبودن یک Outcome چندبعدی است. سایتی که ظاهر جذاب دارد اما کاربر نمیتواند درخواستش را کامل کند یا کسبوکار نمیتواند دادهاش را خارج کند، حرفهای نیست.
| بعد | پرسش | شاهد |
|---|---|---|
| تناسب | آیا Job اصلی مخاطب کامل میشود؟ | Task success و Conversion معتبر |
| وضوح | کاربر میفهمد چه ارائه میکنید و قدم بعدی چیست؟ | تست پیام و First click |
| اعتماد | ادعا، هویت، قیمت و سیاستها قابلراستیآزماییاند؟ | Evidence و مسیر جبران خطا |
| کیفیت | در موبایل، RTL، Keyboard و شبکه کند کار میکند؟ | QA چنددستگاهی و RUM |
| مالکیت | دامنه، حساب، داده و Backup در کنترل کسبوکار است؟ | Access register و Restore/Export test |
| قابلیت تغییر | میتوان محتوا، Integration و پلتفرم را تغییر داد؟ | API/Export/Exit rehearsal |
| اقتصاد | ارزش از TCO و ریسک بیشتر است؟ | مدل هزینه و Outcome سهساله |
سایتساز برای چه پروژههایی مناسب است؟
| سناریو | تناسب معمول | شرط |
|---|---|---|
| سایت معرفی خدمت کوچک | زیاد | فرم، SEO، Analytics و مالکیت دامنه تأیید شود |
| Portfolio یا Event | زیاد | سرعت انتشار و عمر محتوا مهمتر از منطق پیچیده باشد |
| وبلاگ/مجله | متوسط تا زیاد | Workflow تحریریه، Export، URL و Search کافی باشد |
| فروشگاه استاندارد | مشروط | درگاه، مالی، موجودی، ارسال، Refund و API Pilot شوند |
| Marketplace چندفروشنده | کم تا مشروط | Settlement، Role، Workflow و مقیاس اثبات شود |
| محصول SaaS با منطق دامنه | کم برای Core product | ممکن است برای Marketing site مناسب باشد |
| داده حساس/قانونمند | مشروط و پرریسک | امنیت، محل داده، قرارداد و Auditability ضروری است |
اگر مسئله اصلی معرفی، محتوا و گرفتن Lead است، سایتساز میتواند زمان رسیدن به بازار را کم کند. اگر مزیت رقابتی در Workflow اختصاصی، داده پیچیده یا Integration عمیق است، سایتساز عمومی شاید فقط پوسته بازاریابی را پوشش دهد.
چه زمانی سایتساز انتخاب بدی است؟
- نیاز حیاتی شما در API، Permission، Workflow یا پرداخت با راهحل رسمی پشتیبانی نمیشود.
- بار یا الگوی Performance با تست نماینده از سقف پلتفرم عبور میکند.
- شرایط سرویس، پرداخت ارزی یا دسترسی برای تیم ایران پایدار و قابلقبول نیست.
- خروجی داده، رسانه، URL، Redirect یا Domain transfer مبهم است.
- Business continuity به یک Account فردی، شماره خارجی یا پیمانکار وابسته میشود.
- برای دورزدن محدودیتهای بنیادی به دهها Integration شکننده نیاز دارید.
- هزینه سهساله با افزونه، تراکنش، Support، مهاجرت و زمان تیم از گزینه دیگر بیشتر میشود.
Brief یکصفحهای قبل از مقایسه سایتسازها
بدون Brief، Demoهای زیبا معیار شما را تغییر میدهند. Brief باید Outcome و محدودیت را قبل از محصول ثبت کند.
| فیلد | نمونه برای شرکت خدماتی ایران |
|---|---|
| Audience/Job | مدیر کارخانه؛ ارزیابی خدمت و رزرو جلسه |
| Outcome | Lead واجدشرایط، نه صرفاً Page view |
| صفحات | Home، سه Service، Case، About، Contact، Blog |
| Workflow | Form→CRM→مالک فروش→SLA پاسخ |
| Integration | CRM، ایمیل/پیامک، Analytics و Search Console |
| Non-functional | RTL، موبایل، Accessibility، Performance، Backup |
| مالکیت | دامنه، Billing، Admin، Data export در حساب سازمان |
| ریسک | دسترسی سرویس خارجی و وابستگی پرداخت ارزی |
| موفقیت ۹۰روزه | نرخ تکمیل فرم معتبر و زمان پاسخ فروش |
Must/Should/Won’t؛ دامنه MVP را کنترل کنید
فهرست قابلیتها را به Must، Should، Could و Won’t-now تقسیم کنید. Must باید برای تحقق Outcome یا رعایت ریسک ضروری باشد؛ «شاید بعداً لازم شود» Must نیست.
| رده | مثال | قاعده |
|---|---|---|
| Must | دامنه مستقل، فرم سالم، RTL، Export، Analytics | نبودش Knockout است |
| Should | CRM native، Role تحریریه، Staging | ارزش زیاد اما workaround محدود دارد |
| Could | Animation ویژه، چند Template اضافه | فقط پس از سلامت Journey |
| Won’t now | عضویت پیچیده، Marketplace، اپ موبایل | برای جلوگیری از Scope creep ثبت شود |
Knockout criteria؛ پیش از امتیازدهی حذف کنید
برخی معیارها قابل جبران با امتیاز بالا در طراحی نیستند. اگر درگاه موردنیاز، Export، مالکیت دامنه یا دسترسی کشور پشتیبانی نمیشود، محصول را از Shortlist حذف کنید.
- امکان اتصال دامنهای که حساب و Registrant آن در کنترل شماست.
- دسترسی پایدار قانونی/عملی تیم، Billing و Support از محل فعالیت شما.
- پرداخت، مالیات، ارسال یا فرم/CRM حیاتی با تست واقعی.
- Export داده موردنیاز با Field، ID، Media و Relationship کافی.
- HTTPS، Role، MFA/SSO متناسب و Audit در سطح ریسک.
- کنترل Title، Description، URL، Canonical، Redirect و Sitemap موردنیاز.
- Performance و Availability قابلقبول در شبکه کاربران هدف.
Scorecard انتخاب سایتساز
پس از Knockout، گزینهها را با وزن ازپیشتوافقشده بسنجید. امتیاز را با Evidence بنویسید، نه حس Demo.
| معیار | وزن نمونه | Evidence |
|---|---|---|
| تناسب Workflow/Commerce | ۲۰٪ | Pilot end-to-end |
| مالکیت/Export/Exit | ۱۵٪ | فایل Export + Import آزمایشی |
| موبایل/RTL/Accessibility | ۱۵٪ | Device/Keyboard/Screen reader QA |
| SEO و URL control | ۱۰٪ | Page/source/header test |
| Performance/Reliability | ۱۰٪ | RUM/Lab/Status/Incident evidence |
| Integration/API | ۱۰٪ | Sandbox و Failure test |
| Security/Privacy | ۱۰٪ | Contract، controls و verification |
| TCO/Support | ۱۰٪ | هزینه سهساله و SLA |
وزن نمونه نسخه عمومی نیست. فروشگاه وزن Commerce و Integration بیشتری میدهد؛ Portfolio کوچک شاید سرعت تولید و Design را بالا ببرد.
هزینه واقعی سایتساز؛ فراتر از پلن ماهانه
TCO فقط Subscription نیست. هزینه را در افق ۲۴ یا ۳۶ ماه و با سناریوی ارز/رشد حساب کنید.
TCO = Setup + Subscription + Add-ons + Transaction + Integration + Content + Operation + Risk reserve + Exit
| سبد هزینه | نمونه |
|---|---|
| راهاندازی | دامنه، قالب، طراحی، ورود محتوا، آموزش |
| تکرارشونده | پلن، ایمیل، Storage، App، Support |
| متغیر | Transaction fee، پیامک، Automation، Bandwidth |
| داخلی | زمان مدیر محتوا، QA، پشتیبانی و هماهنگی |
| ریسک | نوسان ارز، قطعی، تغییر پلن، Vendor dependency |
| خروج | Export، بازسازی Template، Redirect، Migration و افت موقت |
رایگان یا ارزان میتواند انتخاب درست باشد؛ اما فقط وقتی محدودیت Brand، Storage، Domain، SEO، Export و Support با نیاز شما سازگار است. برای WordPress، راهنمای هزینه و ریسک قالب و افزونه رایگان مدل دقیقتری برای افزونه، Supply chain و Lock-in دارد.
مالکیت دامنه، حساب و دسترسی
دامنه را دارایی کسبوکار بدانید. Registrant، ایمیل بازیابی، MFA، Billing و DNS باید در حساب سازمانی و Access register ثبت شوند؛ پیمانکار میتواند نقش فنی داشته باشد، نه مالک نامشخص دارایی.
| دارایی | مالک پیشنهادی | کنترل |
|---|---|---|
| Domain/Registrar | شخص حقوقی/صاحب کسبوکار | Registrant، Renewal، Auth code، MFA |
| Builder workspace | حساب سازمانی | دو Admin، Role حداقلی، Offboarding |
| Analytics/Search | Property سازمان | Owner مستقل از پیمانکار |
| Media/Copy | Repository سازمان | حق استفاده، Original و نسخه Offline |
| Integration keys | Vault/Owner سازمان | Rotation و revoke |
Policy انتقال دامنههای عمومی و قواعد دامنه .ir یکسان نیستند؛ فرایند روز Registrar/Registry خود را بررسی کنید. برای دامنههای مشمول ICANN، مستند رسمی درباره حق انتقال و Auth-Code توضیح میدهد: FAQ انتقال دامنه برای Registrant.
مالکیت محتوا با قابلیت خروج یکی نیست
ممکن است مالک متن و تصویر باشید، اما نتوانید Design، Component، Workflow یا Code را روی میزبان دیگری اجرا کنید. Export را به سطح Field و سناریوی بازسازی بشکنید.
| لایه | سؤال خروج |
|---|---|
| محتوا | Page/Post/Category/Author/Date/Slug و Relationship خارج میشود؟ |
| رسانه | فایل Original، Alt، Caption و مسیر پیوند حفظ میشود؟ |
| داده کسبوکار | Lead/Order/Customer/Product/Inventory با ID و Timestamp خارج میشود؟ |
| Design | Theme/Style/Component قابل انتقال است یا باید بازسازی شود؟ |
| رفتار | Form، Workflow، Automation و Integration چگونه بازسازی میشوند؟ |
| SEO | URL، Redirect، Canonical، Meta و Schema قابل استخراجاند؟ |
نمونههای رسمی نشان میدهند Export بین محصولات متفاوت است. در مستند جاری Wix، سایت برای کارکرد کامل باید روی زیرساخت Wix اجرا شود؛ در WordPress.com، Export محتوای معمول Posts/Pages/Comments را میدهد اما Theme، Customization، Plugin و خود فایلهای Media در همان Export کامل نیستند. منابع: Export/Hosting در Wix و Export محتوا در WordPress.com. این مثالها حکم رتبهبندی نیستند؛ نشان میدهند باید Export همان پلن و داده خودتان را عملاً آزمایش کنید.
Pilot هفتروزه؛ Demo فروشنده کافی نیست
- یک صفحه واقعی با طول متن، RTL و تصاویر واقعی بسازید.
- فرم را تا Inbox/CRM و پیام تأیید end-to-end اجرا کنید.
- اگر فروشگاه است، محصول Variantدار، تخفیف، پرداخت، Cancel و Refund را تست کنید.
- Title، URL، Canonical، Redirect، Sitemap و Rendered HTML را بررسی کنید.
- موبایل، Keyboard، Error state و شبکه کند را آزمایش کنید.
- یک Export بگیرید، Fieldها و رسانه را بشمارید و Import نمونه انجام دهید.
- یک Admin را حذف، Credential را Rotate و Restore/Version history را تمرین کنید.
نتیجه Pilot باید Pass/Fail و Defect داشته باشد. عبارت «قابل حل با App» بدون نام App، قیمت، مالک، Failure mode و Exit، Evidence نیست.
گام اول ساخت سایت: Outcome و Journey
بهجای «یک سایت مدرن میخواهم»، یک Outcome قابلسنجش تعریف کنید. سپس Journey حداقلی را رسم کنید.
| نوع سایت | Journey اصلی | Outcome | Guardrail |
|---|---|---|---|
| خدمات B2B | Landing→Evidence→Form→Follow-up | Qualified lead | Spam و زمان پاسخ |
| Portfolio | Project→Role→Contact | درخواست مرتبط | حریم خصوصی مشتری |
| فروشگاه | Discover→Product→Cart→Pay→Delivery | سفارش Kept | Refund، خطا و Oversell |
| آموزشی | Search→Article→Subscribe/Course | یادگیری/ثبتنام | کیفیت و Accessibility |
گام دوم: معماری اطلاعات و فهرست صفحات
صفحهها را از Job و Content model بسازید، نه از Template demo. هر صفحه Owner، هدف، مسیر ورودی/خروجی و Lifecycle دارد.
- Homepage: مخاطب، Promise، Evidence و Routeهای اصلی.
- Service/Product: مسئله، دامنه، محدودیت، قیمت/فرایند و قدم بعدی.
- About: هویت، تجربه مرتبط و شواهد قابلراستیآزمایی.
- Contact: روش تماس، SLA پاسخ، Privacy و Success state.
- Policy: شرایط، حریم خصوصی، ارسال/مرجوعی متناسب با کسبوکار.
- Content hub: فقط اگر برنامه تولید و نگهداری واقعی دارید.
برای Taxonomy، Navigation، Search، Facet، Breadcrumb و Link graph از راهنمای ساختار سایت و معماری اطلاعات استفاده کنید.
گام سوم: دامنه و هویت حسابها
- نام کوتاه، قابلگفتن و بدون ابهام املایی شدید انتخاب کنید؛ Keyword در دامنه الزام سئو نیست.
- نام تجاری و امکان استفاده را پیش از چاپ و کمپین بررسی کنید.
- Auto-renew، روش پرداخت جایگزین و هشدار انقضا برای دامنه ثبت کنید.
- DNS را مستند و تغییرها را با TTL و Rollback انجام دهید.
- ایمیل کسبوکار را از همان ابتدا برای Admin، Support و Form تنظیم کنید.
گام چهارم: قالب را با محتوا انتخاب کنید
قالبی که با عکسهای Stock و متن کوتاه زیباست، ممکن است با نام محصول بلند، جدول فارسی، صفحه خطا یا ۳۰ مقاله فروبپاشد. محتوا و State واقعی را وارد کنید.
| تست قالب | سناریو | رد شدن |
|---|---|---|
| Content stress | عنوان کوتاه/بلند، متن کم/زیاد، بدون تصویر | Overflow، قطع محتوا یا Blank بزرگ |
| RTL/Bidi | فارسی + URL + Email + مبلغ + کد | ترتیب یا خوانایی شکسته |
| Responsive | ۳۲۰px، موبایل واقعی، Landscape | Scroll افقی یا CTA پنهان |
| States | Loading، Empty، Error، Success | بنبست یا پیام مبهم |
| Accessibility | Keyboard، Focus، Zoom، Contrast | Task بدون Mouse کامل نشود |
| Performance | صفحه واقعی با App و Font | عبور از Budget |
گام پنجم: Design system کوچک بسازید
حتی در سایتساز، رنگ و فونت را صفحهبهصفحه تغییر ندهید. چند Token و Component کافی است.
- رنگهای Background/Text/Primary/Danger/Success با Contrast قابلقبول.
- مقیاس Type محدود برای Body، H1 تا H3 و Label.
- Spacing scale بهجای Marginهای تصادفی.
- Button، Link، Form field، Card، Alert و Modal با State کامل.
- Content width و Grid مشترک برای خوانایی.
- Icon با Label یا نام دسترسپذیر، نه معنای مبهم.
در صفحه اصلی، معماری پیام از Decoration مهمتر است. راهنمای طراحی صفحه اصلی سایت مدل Audience→Promise→Evidence→Route را توضیح میدهد.
گام ششم: متن و شواهد را پیش از Decoration بنویسید
محتوا باید به سؤال واقعی پاسخ دهد و ادعا را با شاهد همراه کند. «بهترین»، «حرفهایترین» و «تضمینی» بدون معیار اعتماد نمیسازند.
| ادعا | شاهد مناسب | کنترل |
|---|---|---|
| تحویل سریع | فرایند و بازه با شرط | از وعده قطعی بیمبنا پرهیز |
| تجربه صنعتی | Case با نقش و نتیجه | اجازه انتشار مشتری |
| امن | کنترل، Scope و گزارش | HTTPS را با امنیت کامل یکی نکنید |
| رضایت مشتری | Review معتبر و قابلپیگیری | نمونه ساختگی نسازید |
برای هویت، قیمت، Review، حریم خصوصی و مسیر Remedy، راهنمای اعتمادسازی در سایت با شواهد را ببینید.
گام هفتم: فرم را یک Workflow طراحی کنید
فرم فقط چند Field نیست. از Entry تا Validation، Submit، Success، Notification، Ownership و Response SLA یک فرایند است.
| مرحله | کنترل |
|---|---|
| Entry | Label، Required، Format و Privacy روشن |
| Validation | Client + Server، خطای مرتبط و حفظ داده |
| Submit | Loading، جلوگیری از Duplicate و Timeout |
| Success | شماره/پیام تأیید و قدم بعدی |
| Delivery | Inbox/CRM، Spam policy و Retry |
| Operation | مالک Lead، SLA و گزارش پاسخ |
فرم را با ایمیل واقعی، موبایل فارسی/لاتین، شبکه ضعیف، ارسال دوباره و قطع Integration تست کنید. نمایش Success وقتی پیام به مقصد نرسیده، شکست کسبوکار است.
راهنمای W3C/WAI بر Label، Instruction، خطای قابلفهم و اعلام Success تأکید میکند و یادآور میشود Validation سمت Client بهتنهایی امنیت ایجاد نمیکند و داده باید سمت Server نیز اعتبارسنجی شود: اعتبارسنجی دسترسپذیر فرم.
گام هشتم: SEO پایه و قابلخروج
سایتساز باید امکان کنترل Page title، Meta description، Slug/URL، Heading، Alt، Canonical، Robots، Redirect و Sitemap را در Scope شما بدهد. Google Search Essentials بر محتوای مفید، واژههای قابلفهم و Linkهای Crawlable تأکید میکند و هیچ پلتفرمی Index یا رتبه را تضمین نمیکند: Google Search Essentials.
- هر Intent اصلی یک URL مرجع با محتوای متمایز داشته باشد.
- لینک داخلی عنصر واقعی
<a href>و مقصد نهایی باشد. - Title و H1 صفحه را توصیف کنند؛ Keyword stuffing نکنید.
- صفحه عمومی ۲۰۰، Canonical سازگار و Sitemap تمیز داشته باشد.
- Staging پشت Auth/noindex بماند و noindex در Production حذف شود.
- قبل از انتشار، Source/Rendered HTML و Redirectها را آزمایش کنید.
چک کامل Pre-launch و Migration در چکلیست سئو طراحی سایت از Staging تا انتشار آمده است.
گام نهم: Analytics را به تصمیم وصل کنید
Page view بهتنهایی موفقیت نیست. Event dictionary بسازید و Conversion را با سیستم مقصد Reconcile کنید.
| سایت | Event اصلی | Outcome | Guardrail |
|---|---|---|---|
| B2B | form_submit | Qualified lead | Spam و Duplicate |
| فروشگاه | purchase | Paid/Kept order | Refund و پرداخت ناموفق |
| Portfolio | contact_start/complete | درخواست مرتبط | پیام نامرتبط |
| Content | subscribe/next_content | بازگشت یا ثبتنام معتبر | Unsubscribe/Consent |
PII مثل موبایل و ایمیل را بیدلیل وارد URL، Analytics یا Log نکنید. Consent، Retention و Access را مستند کنید.
ساخت سایت با سایتساز برای کاربران ایران
ارزیابی ایران نباید به «RTL دارد یا نه» محدود شود. دسترسی تیم، پرداخت پلن، شبکه کاربر، درگاه، پیامک، دامنه، Support و Exit باید در Pilot دیده شوند.
| ریسک/نیاز | آزمون | برنامه جایگزین |
|---|---|---|
| پرداخت ارزی پلن | Renewal، Invoice و قطع روش پرداخت | حاشیه زمانی و گزینه مهاجرت |
| دسترسی سرویس | Admin/User از اپراتورهای مختلف | Route و Vendor جایگزینِ مجاز |
| درگاه داخلی | Payment→Callback→Verify→Refund | Idempotency و Reconciliation |
| پیامک/CRM | Timeout، Retry و Delivery status | Queue و کانال دوم |
| RTL/Bidi | فارسی+Email+URL+مبلغ+کد | Component قابلاصلاح |
| شبکه | RUM و Device واقعی داخل/خارج | Asset/CDN strategy مجاز |
| قیمت/قانون | ریال/تومان، موجودی، Policy جاری | Source of truth و Owner |
سایتساز خارجی یا ایرانی؟
پاسخ عمومی «همیشه این» وجود ندارد. محصول خارجی ممکن است Editor و اکوسیستم قویتری داشته باشد، اما Eligibility، Billing، Support، درگاه و Continuity برای تیم ایران ریسک بسازند. محصول ایرانی ممکن است پرداخت و Support محلی بهتری دهد، اما API، Export، Performance یا Scale باید اثبات شود. معیار را Capability، Evidence، TCO و Exit قرار دهید؛ نه کشور سازنده.
فروشگاهساز انتخاب میکنید؟
فروشگاه با سایت معرفی فرق دارد. Product/Variant، موجودی، قیمت، تخفیف، سفارش، پرداخت، ارسال، مرجوعی، مالی و Support باید یک Journey یکپارچه بسازند. برای مقایسه SaaS ایرانی، WooCommerce و راهکار اختصاصی با TCO و Pilot، راهنمای انتخاب سایتساز فروشگاهی را بخوانید.
موبایل و RTL؛ Template Responsive کافی نیست
- عرض ۳۲۰px، Zoom، Keyboard و Orientation را تست کنید.
- Sticky header/CTA نباید محتوا یا Focus را بپوشاند.
- Keyboard مناسب شماره موبایل، ایمیل و مبلغ باز شود.
- Tap target، فاصله و پیام خطا برای Touch مناسب باشد.
- متن فارسی راستبهچپ و URL/Email/Code با
dir/bdiدرست نمایش یابد. - Navigation، Search و Form با یک دست و Back browser قابل استفاده باشند.
Google در راهنمای Mobile-first indexing بر همارزی محتوای اصلی، Heading، Metadata و Structured data در موبایل و دسکتاپ و قابلدسترسیبودن Resourceها تأکید میکند: Mobile-first indexing best practices.
دسترسپذیری؛ تست خودکار کافی نیست
Builder ممکن است Component آماده بدهد، اما ترکیب رنگ، ترتیب Heading، متن Link، Label و Widget سفارشی هنوز مسئولیت شماست. چک مقدماتی W3C/WAI برای Keyboard، Focus، Heading، فرم و تصویر نقطه شروع مناسبی است: Easy Checks.
| لایه | آزمون |
|---|---|
| Automated | Issueهای قابلتشخیص در هر Template |
| Keyboard | همه Taskها، Focus، Modal و Menu |
| Screen reader | Name/Role/Value، Heading و Error |
| Visual | Contrast، Zoom، Reflow و Motion |
| User | Task واقعی با افراد دارای نیاز متفاوت |
سرعت؛ App و Widget رایگان نیستند
هر Chat، Tracker، Font، Animation و App هزینه Network/Main thread/Privacy دارد. قبل و بعد از افزودن Integration، Page weight و Journey را بسنجید.
| بودجه | اندازهگیری | تصمیم |
|---|---|---|
| تصویر Hero | فرمت، ابعاد، priority و LCP | Resize/Compress/Preload کنترلشده |
| JavaScript | KB، long task، interaction | حذف Widget کمارزش |
| فونت | Subset، variant و FOIT/FOUT | وزن کمتر و fallback |
| Third-party | Request، CPU، Failure و PII | Consent، delay یا حذف |
| Backend | TTFB، cache-cold و error | پلان/پلتفرم/صفحه را اصلاح کنید |
Core Web Vitals جاری LCP، INP و CLS را در تجربه واقعی میسنجد و توصیه ارزیابی در صدک ۷۵، جدا برای موبایل و دسکتاپ است: Web Vitals. برای سنجش اثر اقتصادی، راهنمای سرعت سایت و UX/Conversion مفید است.
امنیت و حریم خصوصی؛ «میزبانی مدیریتشده» همه مسئله نیست
SaaS بخشی از Patch و زیرساخت را مدیریت میکند، اما Account، Role، MFA، Form، Integration، Content permission و Incident response همچنان با شماست. CMS خودمیزبان مسئولیت Update، Plugin، Backup و Hosting بیشتری میآورد.
- دو Admin سازمانی، MFA و Recovery code امن داشته باشید.
- Role حداقلی برای Editor، Designer، Support و Vendor تعریف کنید.
- App/Plugin را با Source، Scope دسترسی، Update و Exit ارزیابی کنید.
- Secret را در صفحه، Custom code یا Spreadsheet عمومی نگذارید.
- Form، Upload، Login و Checkout را بر اساس ریسک تست کنید.
- Incident contact، revoke access، Backup و Restore روشن باشد.
OWASP ASVS یک پایه قابلارجاع برای تعریف و آزمون کنترلهای امنیت برنامه وب و استفاده در Procurement است؛ سطح و Scope را بر اساس ریسک انتخاب کنید: OWASP ASVS.
Backup با Version history فرق دارد
Undo صفحه، History نسخه و Backup کامل یک چیز نیستند. Backup باید Scope، Retention، Location و Restore test داشته باشد.
| دارایی | نسخه لازم | آزمون |
|---|---|---|
| محتوا/ساختار | Export دورهای | Import نمونه و شمارش |
| Media | Original مستقل | بازشدن و Metadata |
| داده کسبوکار | Lead/Order/Customer export | Field/ID/Timestamp reconciliation |
| Config/Design | Snapshot/Documentation | بازسازی صفحه نمونه |
| Domain/DNS | Zone و Credential register | Rollback تغییر DNS |
راهنمای امنیت کسبوکار کوچک CISA/FCC نیز توصیه میکند Backup داده حیاتی فقط نگهداری نشود و بازیابی آن مرتب آزموده شود: Cybersecurity Planning Guide.
اشتباهات رایج هنگام ساخت سایت با سایتساز
- شروع از قالب: Outcome و محتوا خود را با Demo تطبیق میدهند.
- انتخاب با قیمت ماه اول: App، تراکنش، ارز، عملیات و Exit حذف میشوند.
- دامنه در حساب طراح: مهمترین دارایی خارج کنترل کسبوکار میماند.
- «Export دارد» بدون تست: Design، Media یا Relationship خارج نمیشود.
- افزودن Widget برای هر مشکل: Performance، Privacy و Compatibility افت میکند.
- قالب زیبا با State ناقص: Error/Empty/Long content و موبایل میشکنند.
- SEO بعد از انتشار: URL، رندر و معماری دیر اصلاح میشوند.
- Success جعلی فرم: Lead به CRM نمیرسد اما کاربر پیام موفق میبیند.
- Backup بدون Restore: در Incident معلوم میشود نسخه ناقص است.
- نبود Exit trigger: Lock-in تا بحران ادامه پیدا میکند.
برای تبدیل این خطاها به Evidence، Cause، Fix و Acceptance، اشتباهات رایج طراحی سایت را ببینید.
QA پیش از انتشار
| Lane | نمونه آزمون | Gate |
|---|---|---|
| Content | متن نهایی، لینک، Claim، Alt، Policy | Placeholder و Broken link صفر |
| Functional | Form، Search، Login، Cart، Payment | Journey حیاتی Pass |
| Responsive/RTL | Device، Zoom، Bidi و Keyboard | بنبست یا Overflow صفر |
| Accessibility | Automated+Keyboard+Screen reader | Issue بحرانی صفر |
| Performance | Lab/RUM baseline و network | داخل Budget |
| SEO | ۲۰۰، robots، canonical، render، sitemap | noindex و خطای URL صفر |
| Analytics | Event و Backend reconciliation | Duplicate/PII صفر |
| Operations | Access، Backup، Alert، Rollback | Owner حاضر |
چکلیست روز انتشار سایتساز
- دامنه و DNS در حساب سازمان و Renewal فعال است.
- TLS معتبر و همه Host/Schemeهای فرعی به نسخه اصلی هدایت میشوند.
- Staging محافظت و Production از
noindexناخواسته پاک است. - Homepage و نمونه هر Template مستقیم ۲۰۰ و Canonical صحیح دارند.
- Form/CRM/Email، Login و در صورت وجود Payment end-to-end کار میکنند.
- نسخه موبایل، RTL/Bidi، Keyboard، Zoom و Error state تست شده است.
- Title، H1، Description، Link، Sitemap و Structured data کنترل شدهاند.
- Analytics فقط یک Page view و Conversion معتبر میفرستد.
- Backup/Export تازه و Restore/Import نمونه موجود است.
- Adminها، MFA، Role، Billing و Support contact ثبت شدهاند.
- Dashboard و Alert برای Error، Form و Conversion فعال است.
- Rollback owner و معیار توقف انتشار مشخص است.
نگهداری سایت پس از انتشار
| ریتم | کار |
|---|---|
| هفتگی | Form delivery، Error، Uptime، Backup status و Lead quality |
| ماهانه | Broken link، Content freshness، Access، App، RUM و هزینه |
| فصلی | Restore/Export test، Vendor/plan review، Security و Accessibility sample |
| سالانه | TCO، Outcome، Domain/contract، Architecture و Exit readiness |
| رویدادمحور | تغییر پلن/قیمت/مالکیت، Incident، رشد داده یا Integration failure |
چه زمانی از سایتساز مهاجرت کنیم؟
مهاجرت وقتی منطقی است که شکاف پلتفرم، Outcome یا ریسک را بهطور پایدار آسیب میزند و Workaround گرانتر از انتقال شده است.
| Trigger | Evidence | تصمیم |
|---|---|---|
| قابلیت حیاتی غایب | Lost revenue/operation و Pilot ناموفق | Upgrade، Integration یا migrate |
| Performance ceiling | RUM/Load تحت محتوای بهینه | Platform/architecture review |
| Lock-in عملیاتی | Export ناقص و هزینه بازسازی رو به رشد | خروج مرحلهای پیش از بحران |
| ریسک دسترسی/Billing | Incident تکرارشونده | Continuity plan و migration |
| TCO ناموجه | هزینه بهازای Outcome نسبت به گزینهها | Rebid/Pilot جایگزین |
از روز اول URL inventory، Content export، Media originals و Redirect map بالقوه را نگه دارید. Exit plan بدبینی نیست؛ قدرت مذاکره و تداوم کسبوکار است.
برنامه ۳۰روزه ساخت سایت حرفهای با سایتساز
| بازه | کار | خروجی |
|---|---|---|
| روز ۱–۳ | Outcome، Audience، Journey، Must/Won’t | Brief و KPI |
| روز ۴–۷ | Knockout، TCO، Export/Exit و Shortlist | Scorecard |
| روز ۸–۱۲ | Pilot واقعی و انتخاب | Evidence و قرارداد |
| روز ۱۳–۲۰ | IA، Content، Template و Design system | MVP قابلاستفاده |
| روز ۲۱–۲۵ | Integration، SEO، Analytics و Security | Journey end-to-end |
| روز ۲۶–۲۸ | QA چندلایه و Fix | Go/No-go report |
| روز ۲۹–۳۰ | انتشار، Monitoring و Review | Evidence bundle و Backlog |
پرسشهای متداول
آیا با سایتساز واقعاً میتوان سایت حرفهای ساخت؟
بله، اگر نیاز شما با قابلیت پلتفرم متناسب باشد و محتوا، UX، موبایل، امنیت، SEO، Analytics، مالکیت و عملیات درست طراحی شوند. حرفهایبودن نتیجه است، نه نام ابزار.
سایتساز بهتر است یا WordPress؟
پاسخ به Workflow، مهارت تیم، کنترل، Update، Integration، TCO و Exit بستگی دارد. SaaS معمولاً عملیات زیرساخت را سادهتر و WordPress خودمیزبان کنترل و اکوسیستم بیشتری میدهد؛ هر دو میتوانند Lock-in و هزینه پنهان داشته باشند. Pilot کنید.
سایتساز رایگان برای کسبوکار کافی است؟
برای Prototype ممکن است کافی باشد. برای Production، محدودیت دامنه مستقل، Branding، Storage، Analytics، SEO، Export، Support و Terms را بسنجید. قیمت صفر به معنی TCO صفر نیست.
برای سایت ایرانی چه چیزی را حتماً تست کنیم؟
دسترسی Admin و کاربر از چند اپراتور، RTL/Bidi، فونت، فرم و موبایل فارسی، پرداخت/Callback/Refund، پیامک/CRM، دامنه، Billing، Export و برنامه جایگزین را end-to-end تست کنید.
چگونه از Vendor lock-in سایتساز کم کنیم؟
دامنه و حسابها را سازمانی نگه دارید، محتوا و رسانه Original را جدا ذخیره کنید، Export دورهای و Import نمونه انجام دهید، URL/Redirect inventory داشته باشید، Integration را مستند کنید و Trigger/بودجه خروج را از ابتدا تعیین کنید.
جمعبندی
سایتساز میتواند راهی سریع و اقتصادی برای ساخت سایت حرفهای باشد، اما فقط وقتی ابزار بعد از Outcome انتخاب شود. Brief، Knockout، TCO، مالکیت دامنه و داده، Export/Exit و Pilot را پیش از قالب انجام دهید؛ سپس محتوا، معماری، فرم، SEO، موبایل، RTL، Accessibility، Performance، امنیت و Analytics را با معیار پذیرش بسازید. سایتی حرفهای است که امروز Journey کاربر را سالم کامل کند و فردا نیز بتوانید آن را نگه دارید، توسعه دهید یا با کمترین ریسک از پلتفرمش خارج کنید.
