سایت‌ساز یا کدنویسی اختصاصی؛ راهنمای انتخاب معماری

دو تیم با یک Brief یکسان می‌توانند دو اشتباه متضاد بسازند: تیم اول برای سایت معرفی پنج‌صفحه‌ای، اپلیکیشن اختصاصی و پنل مدیریت سفارشی می‌نویسد؛ تیم دوم فرایند چندنقشی قیمت‌گذاری و تأیید قرارداد را داخل Page builder جا می‌دهد. اولی پول و زمان را پیش از یادگیری می‌سوزاند؛ دومی خیلی زود به سقف Permission، Workflow و Integration می‌رسد. مسئله این نیست که «کدنویسی حرفه‌ای‌تر است» یا «No-code سریع‌تر»؛ مسئله تناسب روش ساخت با ریسک و تغییرپذیری نیاز است.

در این راهنما، سایت‌ساز درگ‌اند‌دراپ، CMS، Headless/Hybrid و توسعه اختصاصی را روی یک طیف بررسی می‌کنیم. خروجی باید یک Decision record قابل دفاع باشد: چه چیزی می‌سازیم، کدام بخش را می‌خریم، چه کنترلی لازم داریم، هزینه ۳۶ماهه چیست و اگر فرض‌ها غلط بود چگونه خارج می‌شویم. برای فرایند قدم‌به‌قدم ساخت یک سایت ساده با Builder، مقاله ساخت سایت با سایت‌ساز راهنمای اجرایی جداگانه‌ای است؛ این صفحه مالک تصمیم Build approach است.

پاسخ کوتاه: سایت‌ساز یا کدنویسی؟

سایت‌ساز زمانی مناسب است که Capability استاندارد، زمان یادگیری کوتاه، تیم فنی محدود و خروجی قابل آزمون باشد. CMS قابل‌توسعه وقتی مناسب است که Content operations استاندارد اما Integration و Template سفارشی لازم دارید. توسعه اختصاصی وقتی توجیه دارد که Workflow، Permission، Data model یا مزیت محصول واقعاً اختصاصی است و تیم توان ساخت و نگهداری امن آن را دارد. Hybrid اغلب انتخاب واقع‌بینانه است: صفحات بازاریابی مدیریت‌شده، در کنار Application یا Service سفارشی.

هیچ گزینه‌ای ذاتاً سریع‌تر، امن‌تر، سئوپذیرتر یا مقیاس‌پذیرتر نیست. این صفات باید با Test و SLA روی نمونه واقعی اثبات شوند.

دوگانه «درگ‌اند‌دراپ یا کد» دقیق نیست

وردپرس می‌تواند Visual، CMS سنتی یا Headless باشد؛ «کدنویسی» نیز ممکن است روی Framework و سرویس‌های Managed بنا شود. بنابراین نام محصول به‌تنهایی معماری را تعیین نمی‌کند.

ابتدا Outcome و Scope را بنویسید

پیش از مقایسه ابزار، Decision brief یک‌صفحه‌ای بسازید:

Outcome: سایت چه نتیجه‌ای برای کاربر و کسب‌وکار می‌سازد؟
Users/Roles: چه کسی محتوا می‌سازد، تأیید می‌کند و مصرف می‌کند؟
Capabilities: Content, Search, Form, Account, Commerce, Workflow, API...
Change profile: کدام بخش هر روز و کدام بخش هر فصل تغییر می‌کند؟
Non-functional: Availability, performance, security, accessibility, SEO
Constraints: time, budget, team, vendor access, Iran payment/network
Horizon: تصمیم را برای چند ماه/سال می‌گیریم؟
Exit: چه داده، URL، Asset و Configuration باید قابل خروج باشد؟

«سایت حرفه‌ای» Requirement نیست. «تیم محتوا بدون Deploy بتواند هفته‌ای ۲۰ صفحه فارسی را با Approval دومرحله‌ای منتشر کند» قابل آزمون است.

Capability inventory: صفحه نمی‌خرید، توان عملیاتی می‌خرید

برای هر Capability برچسب Commodity، Differentiator یا Compliance-critical بگذارید. Commodity را معمولاً می‌خرید؛ Differentiator را جایی سفارشی می‌کنید که مزیت واقعی بسازد؛ بخش حساس را با کنترل و آزمون سخت‌تر انتخاب می‌کنید.

قانون Boundary: کجا Configure و کجا Code؟

هر سفارشی‌سازی هزینه چرخه عمر دارد و هر محدودیت Vendor نیز هزینه فرصت. Boundary خوب بخش پایدار و استاندارد را به پلتفرم می‌سپارد و منطق دامنه را در لایه‌ای نگه می‌دارد که قابل آزمون و مالکیت است.

Configure when:
  requirement fits supported model + upgrade path is safe
Integrate when:
  external system owns truth + API/webhook contract is reliable
Extend when:
  isolated capability has clear interface and lifecycle
Custom-build when:
  domain workflow is differentiating and cannot fit without distortion
Reject when:
  knockout requirement or exit condition fails

اضافه‌کردن ده‌ها Plugin یا Custom code داخل Hookهای مبهم می‌تواند از یک برنامه اختصاصی پرهزینه‌تر شود. برعکس، بازنویسی Login، Media library یا Editor معمولاً ارزش متمایز ایجاد نمی‌کند.

Time-to-market را با Time-to-learning بسنجید

انتشار در یک روز فقط وقتی مزیت است که بتوانید فرضیه درست را آزمایش کنید. Builder برای Landing، Portfolio یا Lead MVP ممکن است سریع‌ترین مسیر یادگیری باشد؛ اما اگر از روز اول Integration و Workflow اصلی حذف شوند، نسخه سریع نماینده محصول آینده نیست.

سه زمان جدا را ثبت کنید:

• Time to first publish: نخستین صفحه عمومی؛
• Time to representative pilot: نخستین مسیر واقعی با داده و Integration؛
• Time to safe change: تغییر بعدی همراه Preview، QA و Rollback.

کدنویسی ممکن است انتشار اول را کند کند اما تغییرهای بعدی را با Component و Test سریع‌تر کند؛ Builder نیز ممکن است شروع سریع اما Regression دستی طولانی داشته باشد. فقط Pilot نشان می‌دهد.

TCO را در افق ۳۶ماهه محاسبه کنید

TCO36 = build + subscription/license + infrastructure
      + integration + content operations + maintenance/security
      + expected incident cost + expected migration/exit cost

قیمت Plan را با ارز، مالیات، واسطه پرداخت، نوسان، محدودیت تمدید و Seat/usage محاسبه کنید. هزینه تیم اختصاصی نیز فقط حقوق Developer نیست. برای تصمیم بازطراحی/بازسازی و Contingency، راهنمای زمان و بودجه بازطراحی سایت مکمل است.

مالکیت را به Data، Code، Domain و Control تفکیک کنید

«مالکیت صددرصد» عبارت دقیقی نیست. ممکن است Domain متعلق به شما باشد ولی Theme قابل خروج نباشد؛ Data export داشته باشید اما روابط، Revision یا Redirectها خارج نشوند؛ Repository داشته باشید اما سرویس ثالث بدون آن کار نکند.

مستند رسمی WordPress مثلاً WXR export را برای Post، Page، Comment، Custom field، Taxonomy و User شرح می‌دهد؛ اما همین Export به‌تنهایی Theme، Plugin behavior، Media binary، Secret و Infra را Restore نمی‌کند. خروج باید روی Scope واقعی آزمایش شود.

سئو: پلتفرم برنده ثابت وجود ندارد

Google پاداشی به «کدنویسی اختصاصی» یا «سایت‌ساز» نمی‌دهد. نتیجه به خروجی عمومی بستگی دارد: HTTP status، محتوای Rendered، URL قابل کشف، Canonical، Title، Structured data، Internal link، Sitemap و عملکرد واقعی. مستند جاری JavaScript SEO گوگل می‌گوید لینک Crawlable باید عنصر <a href> باشد، محتوای لازم باید در Rendered HTML دیده شود و Server-side/Pre-rendering برای کاربر و Crawler همچنان مزیت دارد.

پیش از خرید، روی URL واقعی این Acceptanceها را اجرا کنید:

curl/status: 200, 301, 404/410 meaningful
source/rendered: title, canonical, robots, content parity
links: real href, stable crawlable URLs
index control: per-template index/noindex, sitemap eligibility
schema: valid and matches visible content
migration: custom redirects, no forced chains
logs/tools: Search Console verification and diagnostics

صفحه سایت‌ساز برای سئو Scorecard و Pilot تخصصی Search را عمیق‌تر پوشش می‌دهد.

Performance: از «کد تمیز» و Demo سریع عبور کنید

Builder ممکن است JavaScript و DOM اضافی بسازد؛ Custom code نیز می‌تواند Bundle سنگین، Query کند و Third-party کنترل‌نشده داشته باشد. Template نماینده را با تصویر، فونت فارسی، Consent، Analytics، فرم و Scriptهای واقعی آزمایش کنید. Lab برای Regression مفید است و Field/RUM تجربه واقعی شبکه و دستگاه را نشان می‌دهد.

Core Web Vitals جاری LCP، INP و CLS هستند و ارزیابی Field در صدک ۷۵ Mobile/Desktop انجام می‌شود. Budget را برای JS، CSS، Image، Font، DOM، Third-party و Backend بنویسید و Owner تعیین کنید. راهنمای Core Web Vitals و RUM روش اندازه‌گیری و عیب‌یابی را ارائه می‌کند.

Accessibility: Editor ساده تضمین خروجی دسترس‌پذیر نیست

W3C در ATAG دو سطح را جدا می‌کند: خود Authoring tool باید برای نویسندگان دارای معلولیت قابل استفاده باشد و باید به تولید محتوای منطبق با WCAG کمک کند. در Pilot، فقط Frontend را نسنجید؛ Editor، Keyboard، Label، Heading order، Alt workflow، Caption، Error و Template lock را نیز بررسی کنید.

• آیا نویسنده بدون Mouse می‌تواند Block را مدیریت کند؟
• آیا Component اجازه ساخت Heading order نامعتبر می‌دهد؟
• آیا Alt خالیِ تزئینی با Alt فراموش‌شده فرق دارد؟
• آیا Focus، Reflow، Zoom، Contrast و Error state در Template کنترل می‌شوند؟
• آیا تغییر Content editor می‌تواند Accessibility قراردادشده را بشکند؟

امنیت: Hosted بودن مسئولیت را حذف نمی‌کند

در SaaS، Vendor معمولاً Infra و Patch پلتفرم را مدیریت می‌کند؛ شما همچنان مسئول Account، MFA، Role، App/plugin، Script ثالث، Content، Data، Domain و Integration هستید. در Custom/self-hosted، Secure SDLC، Dependency، Secret، Backup، Logging، Incident و Patch نیز به Scope شما اضافه می‌شود.

OWASP ASVS نسخه پایدار جاری ۵.۰.۰ مبنایی برای تعریف و آزمون کنترل‌های امنیت برنامه وب و حتی Procurement فراهم می‌کند. سطح و Requirement مرتبط را در قرارداد انتخاب کنید؛ صرف وجود SSL یا «امنیت سازمانی» در صفحه فروش Evidence کافی نیست.

Integration: API داشتن به معنی Fit نیست

برای CRM، ERP، PSP، پیامک، Search یا انبار، Capability را در سطح عملیات بسنجید:

راهنمای یکپارچه‌سازی سایت با API و Webhook Contract و Failure handling را عمیق‌تر می‌کند.

مقیاس‌پذیری را به Quota و Degradation تبدیل کنید

«ترافیک بالا» عدد نیست. Peak request، concurrent editor، API rate، build duration، collection size، search index، bandwidth، function execution، form submission و publication frequency را اندازه بگیرید. سپس رفتار نزدیک سقف را آزمایش کنید: Slow، Queue، ۴۲۹، Hard fail یا هزینه بیشتر؟

Load profile: normal / campaign peak / bot spike
Critical route: homepage / product / checkout / account
SLO: availability, latency, error rate
Quota: documented limit + observed limit + headroom
Degradation: cache, read-only, queue, fallback
Recovery: retry, replay, rollback, support escalation

مقاله مقیاس‌پذیری سایت‌سازها ظرفیت، Quota و Trigger مهاجرت را تخصصی‌تر بررسی می‌کند.

Content operations و Design governance

آزادی Drag-and-drop می‌تواند سرعت انتشار را بالا ببرد و هم‌زمان Design drift، Heading بی‌قاعده، Component تکراری و Performance regression بسازد. نقش‌ها را تفکیک کنید: Author محتوا را تغییر دهد، Designer Token و Pattern را، Developer Component را و Publisher Release را تأیید کند.

امکانات مطلوب شامل Reusable component، Design token، Template lock، Draft/preview، Revision، Approval، Schedule، Locale، Audit log و Rollback است. «هرکس هر چیزی را بکشد» Governance نیست.

Technical debt در هر دو مسیر شکل می‌گیرد

Builder debt می‌تواند Appهای متداخل، CSS override، Template fork و Workaround بدون Owner باشد. Custom debt می‌تواند Dependency قدیمی، Test ناکافی، Coupling و دانش متمرکز نزد یک نفر باشد. Debt را با Principal، Interest، Risk و Owner ثبت کنید و برای پرداخت آن Capacity بگذارید. راهنمای مدیریت بدهی فنی این فرایند را پوشش می‌دهد.

Portability و Exit را پیش از ورود امتحان کنید

از Vendor یا تیم بخواهید Export واقعی بدهد و آن را در محیط جدا Restore کنید. Inventory خروج:

• URL، Redirect، Slug، Canonical و Metadata؛
• Content، Relation، Taxonomy، Author، Revision و Locale؛
• Media binary، Alt، Caption و Rights؛
• User/role و داده تراکنش با کنترل Privacy؛
• Form submission، Consent record و Integration mapping؛
• Theme، Component، Token، Custom code و License؛
• Analytics IDs، Event dictionary، Log و Audit؛
• Domain/DNS، Secret rotation و Account handover.

اگر Migration لازم شد، راهنمای مهاجرت از سایت‌ساز به پلتفرم اختصاصی Inventory، Cutover و Hypercare را مرحله‌بندی می‌کند.

ملاحظات ایران: Fit فنی بدون Operability کافی نیست

برای سرویس خارجی، صرف امکان ساخت Account کافی نیست. Eligibility قراردادی، امکان پرداخت و تمدید، نوسان ارز، Risk بسته‌شدن Account، Export، Support، Region داده، CDN/Latency، Domain verification و دسترسی تیم را بررسی کنید. هیچ روش دورزدن شرط سرویس را به‌عنوان معماری پایدار فرض نکنید.

برای محصول داخلی نیز RTL فقط راست‌چین‌کردن نیست: Bidi متن فارسی/لاتین، فونت، جست‌وجوی ی/ک، اعداد، IRR/تومان، تقویم جلالی/ISO، نشانی و موبایل ایران، PSP، پیامک، نقشه و شبکه ناپایدار را در Pilot قرار دهید. Vendor باید Fallback و خروج داشته باشد.

چهار الگوی معماری و Fit آن‌ها

Hybrid می‌تواند Marketing site را از Product app جدا کند، اما Domain، Identity، Navigation، Design system، Analytics و SEO باید Contract مشترک داشته باشند؛ وگرنه دو تجربه ناسازگار می‌سازید.

Knockout criteria را پیش از امتیازدهی تعیین کنید

میانگین امتیاز نباید شکست بحرانی را پنهان کند. نمونه Knockout:

• عدم امکان Export داده یا کنترل Domain؛
• نبود Permission/Audit لازم برای داده حساس؛
• ناتوانی در URL/Redirect/Index control موردنیاز؛
• عدم پشتیبانی Integration یا SLA حیاتی؛
• شکست Accessibility/Performance نماینده بدون مسیر اصلاح؛
• Eligibility یا تمدید غیرقابل اتکا در ایران؛
• نبود Incident response، Backup restore یا Exit قابل آزمون.

فقط گزینه‌های عبورکرده را با وزن Evidence-based مقایسه کنید.

Scorecard انتخاب روش ساخت

وزن‌ها نسخه عمومی نیستند. سایت رسانه‌ای Content operations را بالاتر می‌برد؛ پرتال مالی Security/Audit را؛ کمپین کوتاه Time-to-learning را. Score بدون Evidence «۱ تا ۵» فقط سلیقه را به عدد تبدیل می‌کند.

Pilot نماینده؛ تصمیم را روی Demo نگیرید

یک مسیر عمودی ۱۰ تا ۱۴روزه بسازید که سخت‌ترین بخش‌های واقعی را در بر گیرد:

1. یک Template فارسی با Content واقعی، فونت و تصویر؛
2. نقش Author→Reviewer→Publisher و Rollback؛
3. Form یا Transaction با Validation و Error/Retry؛
4. یک Integration واقعی با Auth، timeout و duplicate؛
5. SEO source/render/status/canonical/schema test؛
6. Keyboard/Screen reader/Reflow و Authoring test؛
7. Performance budget با Scriptهای واقعی؛
8. Export، Restore، Backup و Incident drill.

Version، Plan، Region، Plugin و Dataset را ثبت کنید تا نتیجه بازتولیدپذیر باشد. Roadmap یا اسکرین‌شات فروش Evidence Feature موجود نیست.

سناریوهای تصمیم

سایت خدماتی محلی با ۱۰ صفحه و فرم تماس

Visual/managed builder معمولاً Fit خوبی دارد، اگر Domain/Export، فرم، Spam، RTL، Performance و SEO پایه پاس شوند. Custom build بدون نیاز متمایز Overbuild است.

رسانه فارسی با چند نویسنده و انتشار روزانه

CMS با Workflow، Revision، Taxonomy، Search و Template کنترل‌شده منطقی‌تر است. Builder آزاد بدون Governance یا App اختصاصی بدون Editor بالغ، هر دو Risk دارند.

پرتال B2B با Role، تأیید و اتصال ERP

Application/Hybrid محتمل است: Content عمومی در CMS، Workflow و Data حساس در Service سفارشی. Builder فقط اگر Permission، Audit، API و Failure model را واقعاً پاس کند.

فروشگاه استاندارد در برابر مارکت‌پلیس

فروشگاه استاندارد اغلب از Commerce platform بالغ سود می‌برد. مارکت‌پلیس چندفروشنده با Settlement، Dispute و Role اختصاصی ممکن است Extension یا Custom domain service بخواهد؛ اما Checkout، Payment یا Auth را بی‌دلیل از صفر نسازید.

قرارداد و تحویل: «سایت کار می‌کند» کافی نیست

Acceptance criteria را به خروجی قابل مشاهده وصل کنید: URL inventory، Browser/device matrix، Accessibility level، Performance budget، Security scope، Backup RPO/RTO، Deployment/rollback، Data export، Documentation، Training، License، Source access، Warranty، SLA، Incident و Handover. Accountها و Domain از ابتدا به نام سازمان باشند و دسترسی پیمانکار Least privilege باشد.

اشتباه‌های رایج در انتخاب

• «بدون کد» را «بدون تخصص و عملیات» معنا کردن؛
• کدنویسی اختصاصی را مالکیت/امنیت/سئو/مقیاس نامحدود دانستن؛
• مقایسه Demo خالی Builder با Production سنگین Custom؛
• خرید بر اساس تعداد Feature بدون Workflow واقعی؛
• نادیده‌گرفتن Author، Support و تیم نگهداری؛
• محاسبه هزینه اول به‌جای TCO و Cost of change؛
• API، Backup یا Export را بدون آزمون پذیرفتن؛
• انتخاب برای ترافیک خیالی به‌جای Load profile؛
• ساخت Custom برای Commodity و تحمیل Workaround به Differentiator؛
• مهاجرت را شکست دانستن و Exit را بعداً موکول کردن.

برنامه تصمیم ۱۴روزه

1. روز ۱–۲: Outcome، Capability inventory و Non-functionalها.
2. روز ۳: Boundary Configure/Integrate/Extend/Build و Knockout.
3. روز ۴: Shortlist سه مدل، نه ده برند مشابه.
4. روز ۵–۹: Vertical slice با Content/Role/Integration واقعی.
5. روز ۱۰: SEO/Performance/Accessibility/Security tests.
6. روز ۱۱: Export/restore، failure و rollback drill.
7. روز ۱۲: TCO36 و Exit cost range.
8. روز ۱۳: Scorecard فقط برای گزینه‌های عبورکرده.
9. روز ۱۴: Decision record، Assumption، Owner و Revisit trigger.

منابع معتبر برای ادامه مطالعه

• Google Search Central: JavaScript SEO basics — Rendered content، لینک Crawlable، Status و Rendering.
• web.dev: Core Web Vitals — LCP، INP، CLS و سنجش Field در صدک ۷۵.
• W3C WAI: ATAG overview — دسترس‌پذیری Authoring tool و خروجی تولیدشده.
• OWASP ASVS — Requirements آزمون امنیت برنامه و Procurement.
• WordPress: Tools Export — Scope رسمی WXR برای ارزیابی Portability، همراه با محدودیت‌های عملی آن.

سؤالات متداول

برای سئو سایت‌ساز بهتر است یا کدنویسی اختصاصی؟

هیچ برنده ثابتی وجود ندارد. URL، Status، Rendered HTML، Canonical، Internal link، Schema، Performance و امکان کنترل Index را روی Pilot بسنجید. Custom فقط امکان کنترل می‌دهد؛ کیفیت را تضمین نمی‌کند.

آیا سایت‌ساز برای کسب‌وکار کوچک انتخاب بدی است؟

خیر. برای Capability استاندارد و نیاز به یادگیری سریع می‌تواند بهترین انتخاب اقتصادی باشد، اگر Domain، Export، RTL، فرم، SEO، Performance و دسترسی در ایران پاس شوند و مسیر خروج روشن باشد.

چه زمانی کدنویسی اختصاصی توجیه دارد؟

وقتی Workflow، Permission، Data model، Transaction یا Integration متمایز با Configure/Extend امن Fit نمی‌شود و ارزش آن از TCO، ریسک و توان نگهداری بیشتر است. «شاید بعداً Feature خاص بخواهیم» به‌تنهایی کافی نیست.

آیا وردپرس درگ‌اند‌دراپ است یا کدنویسی؟

وردپرس CMS است و می‌تواند با Block/Site editor یا Page builder بصری، Theme/Plugin سفارشی یا معماری Headless استفاده شود. پاسخ به Configuration واقعی وابسته است، نه نام WordPress.

چگونه Vendor lock-in سایت‌ساز را بسنجیم؟

Export و Restore واقعی Content، Media، Relation، User، URL، Redirect، Metadata، Form data، Theme/Component و Config را آزمایش کنید؛ Domain/DNS، License، API limit، حذف داده و هزینه Exit را نیز در قرارداد ثبت کنید.

جمع‌بندی

انتخاب سایت‌ساز یا کدنویسی، مسابقه آزادی در برابر سادگی نیست. یک تصمیم Boundary است: Capability استاندارد را کجا می‌خریم، مزیت دامنه را کجا می‌سازیم و چه شواهدی نشان می‌دهد این ترکیب در تولید قابل اداره است. با Outcome و Inventory آغاز کنید، Knockout را قبل از Score تعیین کنید، یک Vertical slice واقعی بسازید و SEO، Performance، Accessibility، Security، Integration و Exit را آزمایش کنید. بهترین روش، کمینه معماری‌ای است که نیاز امروز را بدون گروگان‌گرفتن تغییر فردا برآورده کند.