محدودیت سایت‌ساز؛ سنجش طراحی، سفارشی‌سازی و خروج

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

سفارشی‌سازی واقعی یعنی بتوانید یک تجربه را در همه Templateها، Stateها، محتواها و Viewportهای لازم بسازید، نگه دارید و هنگام خروج تحویل بگیرید. این راهنما به‌جای رتبه‌بندی Wix، Shopify، Webflow، Squarespace یا WordPress، روشی تاریخ‌دار برای سنجش Fit ارائه می‌کند؛ چون قابلیت به Editor، Plan، Theme، Region و تاریخ آزمون وابسته است.

محدودیت طراحی را پیش از انتخاب تعریف کنید

محدودیت فقط این نیست که یک رنگ یا فاصله قابل تغییر نباشد. هرجا Outcome موردنیاز شما در یکی از این لایه‌ها قابل ساخت، آزمون، انتشار یا نگهداری نباشد، یک Gap دارید:

این مقاله مالک محدودیت بصری، Design system، Responsive، RTL، Accessibility و چرخه تغییر طراحی است. برای معماری Backend، API و Webhook به راهنمای توسعه سایت‌ساز با کد و API مراجعه کنید.

نام پلتفرم واحد سنجش نیست

یک برند می‌تواند Editor کلاسیک، Studio، Commerce، Enterprise، Themeهای قدیمی و معماری جدید داشته باشد. قابلیت Custom CSS ممکن است فقط در Plan مشخص، Elementهای پشتیبانی‌شده یا IDE خاص وجود داشته باشد. Export نیز ممکن است HTML/CSS را بدهد اما CMS، Ecommerce، Localization یا Form runtime را ندهد.

پس هر ادعا را با این Tuple ثبت کنید:

platform + product/editor + plan + theme/version + region
+ page/template + role + published-output + evidence-url + checked-at

جمله «پلتفرم X واکنش‌گراست» قابل خرید نیست؛ شاهد قابل خرید این است: «در Plan و Editor انتخابی، Card محصول با متن فارسی واقعی در Viewportهای تعیین‌شده Reflow شد و خروجی عمومی همان نتیجه را نشان داد.»

Outcome و Guardrail را جلوتر از Mockup بنویسید

به‌جای «طرح Figma عیناً اجرا شود»، Outcome را بنویسید: کاربر موبایل باید نوع ارسال را بفهمد، Variant را انتخاب کند و بدون Zoom ناخواسته خرید را تمام کند. سپس Guardrailها را اضافه کنید: ترتیب Heading سالم، Keyboard قابل استفاده، LCP/INP/CLS در بودجه، محتوای فارسی بدون بریدگی و تغییر Theme بدون از دست‌رفتن داده.

Pixel parity ممکن است با روش نامناسب، Semantic، Performance و قابلیت ویرایش را قربانی کند. هدف، برابری تصمیم و هویت است؛ نه تقلید هر مختصات از یک Frame ثابت.

Requirement Inventory؛ همه صفحه‌ها و Stateها را ببینید

فقط Home و Product happy path را فهرست نکنید. Inventory حداقل باید این خانواده‌ها را داشته باشد:

• صفحه‌های عمومی: Home، Landing، درباره، تماس، Blog، Article و Legal؛
• فهرست و کشف: Category، Search، Filter، Sort، Pagination/Load more و Empty state؛
• جزئیات: Product/Service، Variant، موجودی، قیمت، تخفیف و محتوای مرتبط؛
• تراکنش: Form، Login، Cart، Checkout، Payment return، Success، Failure و Pending؛
• سیستمی: ۴۰۴، Maintenance، Cookie/Consent، Error، Loading و Skeleton؛
• Locale: فارسی، متن راست‌به‌چپ، عدد/تاریخ/ارز، متن لاتین در فارسی و نسخه چندزبانه؛
• نقش‌ها: بازدیدکننده، مشتری، Editor محتوا، Designer، Developer و Admin.

هر Requirement باید Priority، Hard gate یا Preference، Owner، روش آزمون و شاهد قبول داشته باشد. «پشتیبانی از طراحی سفارشی» بدون Test case قابل تفسیر فروشنده است.

Hard Gate را از امتیازدهی جدا کنید

یک امتیاز بالا نمی‌تواند نبود Checkout سازگار، مالکیت دامنه، Export حیاتی یا دسترس‌پذیری حداقلی را جبران کند. ابتدا Knockoutها را Pass/Fail کنید؛ فقط گزینه‌های عبوری وارد امتیازدهی شوند.

امنیت حساب، دامنه، App و مسئولیت مشترک را جداگانه با چک‌لیست امنیت سایت‌ساز SaaS بسنجید.

طراحی سیستم؛ آزادی بدون قاعده بدهی می‌سازد

وجود Color picker یا Drag-and-drop به معنای Design system نیست. حداقل به Tokenهای رنگ، Typography، Space، Radius، Border، Shadow، Breakpoint و Motion؛ Componentهای نام‌دار؛ Variantها؛ Stateها؛ و قواعد استفاده نیاز دارید. اگر هر Editor بتواند مقدار دلخواه وارد کند، آزادی اولیه به ناهمگونی و هزینه QA تبدیل می‌شود.

سلسله‌مراتب پیشنهادی این است:

1. Primitive: رنگ و اندازه خام؛
2. Semantic: متن اصلی، سطح هشدار، فاصله Section؛
3. Component: ارتفاع دکمه، Padding کارت، Border ورودی؛
4. Template: چیدمان خانواده صفحه؛
5. Instance: محتوای هر رکورد، نه Style دلخواه هر صفحه.

WordPress Block Themeها، برای نمونه، با theme.json و Global Styles رسمی می‌توانند تنظیمات و Styleهای Core، Theme و User را ساختار دهند. وجود این Surface تضمین کیفیت نیست؛ باید Governance و آزمون خروجی هم وجود داشته باشد.

Component باید Contract داشته باشد

برای Button فقط رنگ و Radius کافی نیست. Contract شامل Label، Icon، Size، Variant، Loading، Disabled، Focus، طول متن، Direction، Event، Analytics و حالت خطا است. Card نیز نسبت تصویر، عنوان چندخطی، قیمت، تخفیف، Badge، موجودی و CTA دارد.

پیش از انتخاب، یک Component سخت را بسازید: Card محصول با عنوان فارسی ۷۰نویسه‌ای، برند لاتین، قیمت تومان، تخفیف، تصویر دیررس و حالت ناموجود. اگر تیم برای هر Instance مجبور به Override دستی شد، Component model مناسب مقیاس شما نیست.

Template و Block؛ انعطاف باید ویرایش‌پذیر بماند

بلوک‌های بسیار درشت، نیاز واقعی را پوشش نمی‌دهند؛ بلوک‌های بسیار ریز، Editor را به جنگل تنظیمات تبدیل می‌کنند. Granularity باید با وظیفه ویرایشگر هماهنگ باشد. Header و Product form معمولاً Guardrail بیشتری از یک بخش Editorial می‌خواهند.

در معماری Theme فعلی Shopify، برای نمونه، Template، Section و Block نقش‌های جدا دارند و Blockها می‌توانند Theme، Section-local یا App-provided باشند. راهنمای رسمی نیز درباره Granularity زیاد و پیچیدگی Editor هشدار می‌دهد. این را «Shopify نامحدود است» ترجمه نکنید؛ همان Theme، Schema، Template type، Plan و Limitهای جاری باید در PoC سنجیده شوند: راهنمای Sections و Blocks در Shopify.

Responsive را با سه آیکن Device تأیید نکنید

Responsive یک مجموعه Screenshot نیست؛ رفتار پیوسته Layout با تغییر Viewport، محتوا، Zoom و Input است. Canvas دسکتاپ/تبلت/موبایل فقط چند Sample است. عرض‌های بین Breakpoint، Landscape، گوشی کوچک، نمایشگر بزرگ و Split-screen را نیز بکشید و ببینید.

چهار چیز را جدا بیازمایید:

• Structure: ترتیب DOM و رابطه Parent/Child؛
• Layout: Grid/Flex، Wrap، Order، Min/max و Container؛
• Style: اندازه، فاصله، Typography و نمایش؛
• Content: متن، تصویر و داده‌ای که غالباً میان Breakpointها مشترک است.

رفتار Cascade پلتفرم‌ها یکسان نیست. در سند فعلی Wix Studio درباره Breakpointها، تغییر Design/Layout از Breakpoint بزرگ به کوچک Cascade می‌شود اما تغییر Data و Structure می‌تواند همه Breakpointها را تحت تأثیر بگذارد. Webflow نیز مدل Cascade خود را مستند کرده است. این‌ها را با محصول دقیق خودتان و روی خروجی Publish شده امتحان کنید.

آزمون Viewport پیوسته

به جای فقط ۱۴۴۰، ۷۶۸ و ۳۹۰ پیکسل، عرض را آرام از حداقل تا حداکثر تغییر دهید و Overlap، Overflow، Gap، Line break و عنصر Fixed را ثبت کنید. سپس Zoom مرورگر، Text resize، Orientation و صفحه‌کلید موبایل را اضافه کنید.

320 → 360 → 390 → 412 → 480 → 600 → 768 → 820 → 1024 → 1280 → 1440
Fixtures: long-fa | mixed-fa-en | missing-image | validation-error | keyboard-open
Assertions: no-overlap | no-content-loss | focus-visible | reading-order | CTA-reachable

اگر فقط با Hideکردن محتوای مهم در موبایل طرح سالم می‌شود، مسئله حل نشده؛ Information architecture یا Component باید بازطراحی شود.

RTL فقط راست‌چین‌کردن متن نیست

در محصول فارسی، Direction، Alignment و Order سه مفهوم جدا هستند. آیکن Next/Back، Progress step، Breadcrumb، Timeline، Carousel، Price، شماره تلفن، URL، کد رهگیری و متن ترکیبی فارسی/لاتین هرکدام رفتار مشخص می‌خواهند.

Corpus آزمون فارسی بسازید:

• ی/ی و ک/ک، نیم‌فاصله، ارقام فارسی/لاتین و جداکننده هزارگان؛
• نام شخص و شرکت بسیار کوتاه/بلند، ایمیل و URL داخل متن RTL؛
• تومان/ریال همراه با تخفیف، بازه قیمت و Variant ناموجود؛
• تاریخ شمسی/میلادی و منطقه زمانی بدون ادعای پشتیبانی ذاتی؛
• جدول، Chart، Code، شماره سفارش، OTP و پیام خطای فرم؛
• فونت فارسی با Weight واقعی، Fallback و مجوز روشن.

Mirror کردن همه Iconها نیز اشتباه است: Arrow جهت‌دار ممکن است Mirror شود، اما لوگو، Play، Check یا نماد استاندارد لزوماً نه.

Accessibility بخشی از سفارشی‌سازی است

اگر Editor اجازه ظاهر دلخواه می‌دهد اما Semantic و Focus را نمی‌توان درست کرد، سطح کنترل ناقص است. Navigation، Heading، Link/Button، Label/Description، Validation، Modal، Accordion، Carousel، Menu و Toast را فقط با Mouse تست نکنید.

برای WCAG ۲.۲ حداقل این Fixtureها را داشته باشید: Keyboard-only، Focus visible/order، Screen reader smoke test، ۲۰۰% Text resize، Reflow، Contrast، Reduced motion، Error identification و Target spacing. معیار Target Size (Minimum) در سطح AA عموماً ۲۴×۲۴ CSS pixel یا فاصله/استثناهای تعریف‌شده است؛ ۴۴×۴۴ را به‌اشتباه الزام عمومی AA معرفی نکنید. منبع تصمیم، WCAG ۲.۲ رسمی W3C است.

Audit داخلی پلتفرم مفید است اما کامل نیست. برای نمونه Webflow در سند جاری می‌گوید Audit panel فقط چند Check پراثر دارد و Componentها را کامل بررسی نمی‌کند. Pass شدن ابزار با Accessibility conformance برابر نیست.

Custom CSS؛ از Escape hatch تا وابستگی شکننده

CSS می‌تواند Gap کوچک را رفع کند، اما اگر بر Selector خصوصی، ID تولیدی یا DOM داخلی Vendor تکیه کند، Update بعدی آن را می‌شکند. برای هر Rule این مشخصات را نگه دارید: Owner، Purpose، Scope، Selector stability، Browser/RTL impact، Tested version و حذف‌پذیری.

ترتیب Escalation پیشنهادی:

1. تنظیم Native و Token سراسری؛
2. Component/Variant یا Block قابل پشتیبانی؛
3. CSS روی Class عمومی و مستند؛
4. Extension/App رسمی با Scope محدود؛
5. Custom component یا Code با Repository، Test و Rollback؛
6. Hybrid/Headless/Migration وقتی Patchها از محصول بزرگ‌تر شده‌اند.

وجود Custom CSS در یک محصول را به «دسترسی کامل به کد» تعبیر نکنید. سند فعلی Wix درباره Custom CSS نیز از Element و Classهای پشتیبانی‌شده سخن می‌گوید؛ محصول/IDE و Surface واقعی را تاریخ‌دار ثبت کنید.

Code Injection مالکیت Runtime نمی‌دهد

قرار دادن HTML/JavaScript در Header یا Embed ممکن است ظاهر یا Integration بسازد، اما Rendering pipeline، Server، Deployment، Secret management و APIهای داخلی Vendor را در اختیار شما نمی‌گذارد. Script سراسری می‌تواند Consent، CSP، Performance، Accessibility و امنیت Supply chain را تغییر دهد.

Secret، تصمیم قیمت، Permission یا تأیید پرداخت را در Browser قرار ندهید. وقتی نیاز از Style به Data/Identity/Workflow می‌رود، مسئله دیگر صرفاً طراحی نیست و باید با Trust boundary و Backend امن بررسی شود.

Theme Fork و Override debt

سه مسیر سفارشی‌سازی هزینه متفاوت دارند: تنظیم روی Theme استاندارد، Child/Extension پشتیبانی‌شده، یا Fork عمیق. Fork آزادی می‌دهد اما Merge Update، Security fix، Compatibility و Bus factor را به تیم منتقل می‌کند.

Override debt را اندازه بگیرید: تعداد Overrideهای محلی، Selectorهای خصوصی، Templateهای Duplicate، Appهای مؤثر بر UI، خطوط CSS/JS، Regressionهای Update و ساعت ماهانه نگهداری. وقتی یک تغییر Token به ده‌ها Patch نیاز دارد، معماری Design شکسته است.

Staging، Version و Rollback را در Demo جست‌وجو کنید

پیش‌نمایش زیبا بدون چرخه انتشار امن کافی نیست. بررسی کنید آیا Draft/Preview از Production جداست؛ چند نفر هم‌زمان ویرایش می‌کنند؛ History چه چیزی را برمی‌گرداند؛ Theme Update چگونه Diff می‌شود؛ و آیا Rollback محتوا، Layout و Code را با هم پوشش می‌دهد.

یک آزمایش واقعی اجرا کنید: Component اصلی را تغییر دهید، سه صفحه و دو Breakpoint را بازبینی، نسخه را منتشر، سپس Rollback کنید. Screenshot قبل/بعد و زمان Recovery را ثبت کنید.

ویرایشگر محتوا به Guardrail نیاز دارد

بهترین طراحی اگر با اولین عنوان بلند یا تصویر بی‌نسبت بشکند، قابل بهره‌برداری نیست. Roleها و Editor UI باید مسئولیت را جدا کنند: Content owner متن و Media را تغییر دهد؛ Designer Token/Template؛ Developer Code/Integration؛ Publisher انتشار.

Limitهای هوشمند مانند تعداد Variant، Range فاصله، نسبت تصویر، Max length راهنما، Required Alt و Preview State از خطا پیشگیری می‌کنند. قفل‌کردن همه چیز نیز عملیات را کند می‌کند؛ سطح آزادی باید بر اساس Risk هر Component باشد.

SEO را روی HTML عمومی بسنجید

وجود فیلد Title و Meta فقط SEO پایه را نشان می‌دهد. Source و Render عمومی را برای Heading، Canonical، robots، Sitemap، Status/Redirect، Pagination، Structured data، Internal link و محتوای وابسته به JavaScript بررسی کنید. این مقاله وارد ممیزی کامل SEO نمی‌شود؛ روش نماینده در راهنمای سنجش SEO Fit سایت‌ساز آمده است.

محدودیت طراحی وقتی SEO را تهدید می‌کند که مثلاً Heading صرفاً Style است، Link با Element غیرمعنایی ساخته می‌شود، Template اجازه Canonical درست نمی‌دهد یا صفحه‌های Filter URL کنترل‌پذیر ندارند.

Performance را از Screenshot نمی‌توان فهمید

یک صفحه خالی با Theme ساده نماینده سایت واقعی نیست. Theme، Font فارسی، App، Analytics، Chat، Carousel، Video و Custom code را در Pilot قرار دهید؛ سپس Field/Lab را جدا، Templateها را جدا و p75 کاربران هدف را بسنجید.

کنترل مستقیم Server تنها راه Performance نیست و نداشتن آن نیز شکست قطعی نیست. سؤال این است که آیا Outcome و Budget شما با ابزارهای پلتفرم، حذف App، Media policy و Escalation پشتیبانی قابل دستیابی و پایدار است.

Export را به پنج بسته تقسیم کنید

Download یک ZIP برابر خروج کامل نیست. در Snapshot رسمی ۱۲ اوت ۲۰۲۶، Webflow Code Export HTML/CSS/JS/Asset را در Plan واجدشرایط می‌دهد اما CMS، Ecommerce، User Accounts، Localization و برخی Functionها در بسته اجرایی نیستند. Squarespace نیز Export محدود XML دارد و بسیاری از Page typeها، Style و Custom CSS را صادر نمی‌کند. این مثال‌ها حکم «خوب/بد» نیستند؛ نشان می‌دهند باید بسته خروج خودتان را واقعاً Restore کنید.

Vendor Lock-in صفر نمی‌شود؛ قابل مشاهده می‌شود

Lock-in ابعاد مختلف دارد: Data، Design، Runtime، Identity، Integration، Operations، Commercial و Skill. حتی Open-source نیز می‌تواند با Theme اختصاصی، Pluginهای نادر و تیم تک‌نفره Lock-in بسازد. SaaS نیز ممکن است برای دامنه ساده شما Exit قابل قبول داشته باشد.

قفل را با زمان و هزینه یک Exit drill بسنجید، نه با برچسب. اگر خروج قرار است بازسازی کامل باشد، Scope، بودجه، URL map، Content export و Deadline را از روز انتخاب بدانید. اجرای مهاجرت واقعی متعلق به Runbook مهاجرت از سایت‌ساز است.

TCO سفارشی‌سازی فقط اشتراک نیست

مدل سه‌ساله را با این اجزا بسازید:

TCO = plan + seats + theme + apps + commerce/usage + storage/bandwidth
    + design/build + Persian/RTL fixes + accessibility remediation
    + QA/regression + update/incident + specialist + FX/tax/payment
    + export rehearsal + expected migration/exit

«WordPress همیشه ارزان‌تر» یا «SaaS همیشه کم‌هزینه‌تر» نتیجه معتبر نیست. WordPress کنترل بیشتر همراه با Hosting/Security/Update/QA می‌آورد؛ SaaS بخشی از عملیات را Bundle می‌کند اما ممکن است Seat/App/Transaction/Exit هزینه بسازد. Workload و توان تیم نتیجه را تعیین می‌کنند.

Scorecard وزن‌دار پس از Hard Gate

برای گزینه‌های عبوری، وزن‌ها را بر اساس کسب‌وکار خودتان تعیین کنید. نمونه:

امتیاز هر سلول باید Confidence داشته باشد: سند رسمی جاری، مشاهده پنل، PoC، یا ادعای فروش. یک ۵ از ۵ مبتنی بر دمو با Confidence کم نباید با آزمون Production-equivalent برابر باشد.

PoC هفت‌روزه سفارشی‌سازی

1. روز ۱: Plan/Editor/Theme، Roles، Hard gate و Capability register را قفل کنید.
2. روز ۲: Tokenها و سه Component سخت با همه Stateها را بسازید.
3. روز ۳: Home، Listing، Detail، Form و Error را با داده واقعی پیاده کنید.
4. روز ۴: RTL/فارسی، Viewport پیوسته، Zoom و Keyboard را آزمایش کنید.
5. روز ۵: HTML/SEO/Performance/A11y و App/Custom code را روی Publish بسنجید.
6. روز ۶: Editor task، Update، Version، Rollback و Recovery را اجرا کنید.
7. روز ۷: Export/Restore، TCO، Gap و Go/Conditional/No-go را ثبت کنید.

برای پروژه بزرگ، PoC را با Journey و Failure واقعی توسعه دهید؛ راهنمای انتخاب سایت‌ساز پروژه بزرگ مرز Capability، Scale، TCO و Lock-in را عمیق‌تر پوشش می‌دهد.

Acceptance Matrix طراحی

نتیجه PoC را با «خوب به نظر می‌رسد» تحویل ندهید:

• Token سراسری با یک تغییر کنترل‌شده روی همه Templateهای هدف اعمال شد.
• Componentهای حیاتی تمام State، متن بلند، RTL و تصویر Missing را تحمل کردند.
• هیچ Overflow یا Content loss در Viewport/Zoom/Keyboard fixture دیده نشد.
• Keyboard، Focus، Label، Error و Screen reader smoke test عبور کردند.
• HTML عمومی، Metadata و Link/Heading مورد انتظار را داشت.
• بودجه Performance با Appها، Font و Analytics واقعی سنجیده شد.
• Editor غیرطراح سه Task را بدون شکستن Design انجام داد.
• نسخه تغییر کرد، منتشر شد و Rollback زمان‌دار موفق بود.
• Export به محیط خنثی رفت و Gapهای Data/Design/Behavior مستند شدند.

شرایط ایران را در Design QA وارد کنید

Iran fit فقط پرداخت اشتراک نیست. Eligibility قراردادی شخصیت/کشور، روش پرداخت و تمدید، دسترسی شبکه، CDN/Font/Map/Analytics، پاسخ پشتیبانی، درگاه/پیامک، Privacy و امکان Export را بررسی کنید؛ هیچ توصیه‌ای را بر دورزدن Terms یا کنترل‌های دسترسی بنا نکنید.

QA را روی اینترنت ثابت و موبایل، Android میان‌رده/ضعیف، WebView، فونت فارسی واقعی و Journey پرداخت/OTP انجام دهید. محدودیت سرویس ثالث ممکن است فقط در Production ایران آشکار شود، نه در Preview طراح.

مطالعه موردی؛ فروشگاه پوشاک ایرانی

تیم به صفحه محصول با Variant رنگ/سایز، Badge موجودی، قیمت تخفیف‌خورده، راهنمای سایز، Review، Sticky CTA و Checkout فارسی نیاز دارد. در Demo، Home آزادانه طراحی می‌شود؛ اما Product form بخشی کنترل‌شده، Error state محدود و Export Behavior ناقص است.

تیم سه گزینه دارد: پذیرش Theme استاندارد با تغییر هویت در Tokenها؛ Extension محدود و تست‌شده برای Gapهای واقعی؛ یا انتخاب پلتفرم دیگر. بازنویسی Product form با Script مرورگر برای رسیدن به Mockup، چون Payment/State/Accessibility را پرریسک می‌کند، رد می‌شود. این تصمیم نه «سایت‌ساز بد است» و نه «طراحی اختصاصی همیشه بهتر»؛ Fit میان Outcome و سطح کنترل است.

چه زمانی سایت‌ساز انتخاب خوبی است؟

وقتی Journey و Content model با Primitiveهای پلتفرم هم‌راستا است؛ تمایز برند با Token/Component قابل دستیابی است؛ عملیات کوچک ترجیح می‌دهد Hosting/Update Bundle باشد؛ Export پذیرفته‌شده است؛ و PoC RTL/A11y/Performance را تأیید می‌کند، سایت‌ساز می‌تواند سریع و کم‌ریسک باشد. راه ساخت و اداره چنین پروژه‌ای در راهنمای ساخت سایت حرفه‌ای با سایت‌ساز آمده است.

چه زمانی محدودیت به Trigger تغییر تبدیل می‌شود؟

یک Gap منفرد الزاماً مهاجرت نمی‌خواهد. ابتدا Configure، Theme/Component، App رسمی یا Extension امن را بسنجید. اما این علائم Trigger جدی‌اند:

• Hard gate Revenue، حقوق، Accessibility یا امنیت قابل رفع نیست؛
• Override debt و Regression هر Release در حال رشد است؛
• Template حیاتی، Data model یا Workflow تحت کنترل لازم نیست؛
• Quota/Performance/Integration با رشد Workload ناسازگار شده است؛
• Export drill دارایی حیاتی را بازنمی‌گرداند؛
• TCO تمدید Patchها از جایگزینی مرحله‌ای بیشتر شده است.

برای تشخیص اینکه مشکل واقعاً Design است یا Scale/Quota، از مدل مقیاس‌پذیری سایت‌ساز استفاده کنید.

سایت‌ساز رایگان، نسخه کوچک همان تصمیم نیست

Plan رایگان ممکن است Domain، Branding، Analytics، Custom code، Storage، Form، Role، SEO control یا Export متفاوتی داشته باشد. قابلیت موجود در صفحه فروش محصول Pro را به Plan رایگان نسبت ندهید. برای پروژه آزمایشی هم Exit و مالکیت دامنه مهم است؛ راهنمای محدودیت سایت‌ساز رایگان این Gateها را جدا بررسی می‌کند.

Runbookهای ضروری

شکستن Responsive پس از ویرایش

آخرین تغییر Structure/Data/Style را جدا، Component و Cascade را Trace، نسخه قبلی را مقایسه و در صورت عبور از Budget بازگردانی کنید. فقط Viewport گزارش‌شده را Patch نکنید؛ بازه کامل را دوباره بسنجید.

Regression پس از Update Theme یا Platform

Version و Change log را ثبت، Visual/A11y smoke test را روی Templateهای نماینده اجرا، Selector/Extension متأثر را پیدا و Feature را Rollback/Disable کنید. Patch اضطراری باید Owner و Expiry داشته باشد.

شکست محتوای فارسی

Fixture متن، Font/Fallback، Direction/Bidi، Width/Wrap و Data normalization را بررسی کنید. متن واقعی را کوتاه نکنید تا Bug پنهان شود؛ Contract Component را اصلاح کنید.

محدودیت تازه در پلن یا قابلیت

Evidence تاریخ‌دار، Contract و Scope اثر را جمع، Cost/Gap را به Scorecard برگردانید و میان Upgrade، Workaround محدود، جایگزینی Extension یا Exit تصمیم بگیرید.

آمادگی خروج

Exportهای Data/Media/Code/SEO را بگیرید، Count/Relation/Checksum را تطبیق، رفتارهای غیرقابل‌صدور را Inventory و یک صفحه نماینده را در مقصد Restore کنید. خروجی صرفاً دانلودشده، Backup آزموده نیست.

برنامه ۳۰/۶۰/۹۰روزه

۳۰ روز: Contract و Pilot

Outcome، Inventory، Hard gate، Corpus فارسی، Token/Component contract و PoC منتشرشده را کامل کنید. خرید نهایی باید پس از Gap register و Export drill باشد.

۶۰ روز: System و Governance

Tokenها، Componentها، Templateها، Roleها، Content guardrail، Staging/Release/rollback و Regression suite را تثبیت کنید. Overrideهای بدون Owner را حذف یا ثبت کنید.

۹۰ روز: Operate و Exit-ready

Performance/A11y/SEO field checks، Update drill، TCO واقعی، Vendor evidence و Restore دوره‌ای را به عملیات اضافه کنید. Triggerهای Extend/Hybrid/Migrate را به‌صورت عددی بازبینی کنید.

موضوعات مکملی که به مقاله مستقل نیاز دارند

• آزمایشگاه مقایسه Design surface سایت‌سازها با Fixture فارسی و Screenshot diff تاریخ‌دار؛
• Starter kit Design token/Component contract برای Editorهای بصری؛
• Visual regression و Accessibility regression suite برای Template/Breakpointهای سایت‌ساز؛
• ابزار سنجش Override debt، Selector stability و Theme update risk؛
• Export/Restore lab برای Content، Design، Behavior، URL و Media در پلتفرم‌های رایج.

پرسش‌های متداول محدودیت سایت‌ساز

آیا سایت‌سازها طراحی را همیشه محدود می‌کنند؟

هر پلتفرم Surface و Guardrail دارد؛ حتی کدنویسی اختصاصی نیز با بودجه، Framework و توان تیم محدود است. سؤال درست این است که Plan/Editor/Theme موردنظر، Requirementهای حیاتی شما را با خروجی قابل آزمون پوشش می‌دهد یا نه.

آیا دسترسی به CSS یعنی سفارشی‌سازی کامل؟

خیر. CSS ظاهر Surfaceهای پشتیبانی‌شده را تغییر می‌دهد، اما لزوماً DOM، Data، Checkout، Backend، Deployment یا Export را در اختیار شما نمی‌گذارد. Selector خصوصی و Code injection نیز بدهی Update می‌سازند.

برای طراحی فارسی چه چیزی را در سایت‌ساز تست کنیم؟

RTL و ترتیب، متن ترکیبی، ی/ک و نیم‌فاصله، عدد/ارز/تاریخ، فونت و Fallback، عنوان بلند، فرم/خطا/OTP، جدول و همه Viewportها را با داده واقعی و روی نسخه منتشرشده بیازمایید.

آیا سایت‌ساز برای SEO ضعیف‌تر از WordPress است؟

این حکم عمومی معتبر نیست. کنترل URL/Metadata/Canonical/Robots/Schema، HTML Renderشده، Performance، Internal link و Export را برای Use case خود بسنجید. WordPress نیز با Theme/Plugin نامناسب می‌تواند خروجی ضعیف داشته باشد.

از کجا بفهمیم زمان مهاجرت رسیده است؟

وقتی Hard gate رفع‌ناشدنی است، Override debt و Incident رشد می‌کند، Workflow/Data/Scale لازم قابل کنترل نیست، Export حیاتی ناقص است یا TCO ادامه از تغییر بیشتر شده، گزینه Extend/Hybrid/Migrate را با PoC و Runbook مقایسه کنید.

جمع‌بندی

محدودیت سایت‌ساز با تعداد Widget یا زیبایی Template سنجیده نمی‌شود. سطح کنترل از Token و Component تا Template، Responsive، RTL، Semantic، Lifecycle و Export ادامه دارد. هر ادعا باید به Plan/Editor/Theme، تاریخ، صفحه نماینده و خروجی عمومی متصل باشد.

اگر Hard gateها را زود جدا کنید، Design system را به‌جای Override بسازید، فارسی و Accessibility را در PoC بیاورید و Exit را واقعاً تمرین کنید، انتخاب شما از جدال «سایت‌ساز یا کدنویسی» عبور می‌کند و به تصمیمی قابل دفاع درباره Fit، هزینه و ریسک تبدیل می‌شود.