انتخاب سایت‌ساز فروشگاهی؛ معیار، مقایسه و تست خرید

سایت‌ساز فروشگاهی فقط ظاهر فروشگاه را انتخاب نمی‌کند؛ روش ثبت موجودی، دریافت پول، تحویل سفارش، مرجوعی، اندازه‌گیری و حتی امکان خروج شما را تعیین می‌کند. یک Demo زیبا ممکن است در هفته اول عالی باشد و شش ماه بعد، وقتی سه انبار، پنج‌هزار Variant یا اتصال حسابداری دارید، به گلوگاه عملیات تبدیل شود.

پس «بهترین سایت‌ساز فروشگاهی» برنده ثابت ندارد. بهترین گزینه، کم‌هزینه‌ترین پلتفرمی است که نیازهای حیاتی امروز و سناریوی رشد واقع‌بینانه را با شواهد قبول می‌کند، ریسک قانونی/امنیتی قابل‌مدیریت دارد و در روز جدایی، داده و دامنه را گروگان نمی‌گیرد. این راهنما به‌جای رتبه‌بندی تبلیغاتی، روش Shortlist، محاسبه TCO، Proof of Concept، قرارداد و Migration را برای کسب‌وکار ایرانی ارائه می‌کند.

پاسخ کوتاه: کدام معماری برای چه فروشگاهی؟

Marketplace یا شبکه اجتماعی می‌تواند Channel فروش باشد، اما جای دارایی Owned، Export داده و رابطه مستقیم با مشتری را کامل نمی‌گیرد. همچنین «Custom» به‌خودی‌خود حرفه‌ای‌تر نیست؛ اگر Differentiator مشخصی ندارید، ساخت دوباره Catalog، Checkout و Admin معمولاً ریسک غیرضروری است.

اول مسئله کسب‌وکار را بنویسید، نه فهرست Feature

پیش از باز کردن صفحه قیمت، یک Commerce brief بسازید. بدون آن، Featureهای جذاب Vendor به Requirement تبدیل می‌شوند و نیاز واقعی شما گم می‌شود.

پلتفرم نمی‌تواند اقتصاد سفارش یا عملیات ضعیف را نجات دهد. پیش از Scale، حاشیه هر سفارش، ظرفیت ارسال و قیف Paid→Delivered→Kept را با راهنمای بازاریابی فروشگاه اینترنتی روشن کنید.

Must-have، Should-have و Knockout را جدا کنید

فهرست ۲۰۰ Feature به فروشنده اجازه می‌دهد با تیک‌های سطحی برنده شود. Requirement را به سناریوی قابل آزمون و سه سطح تبدیل کنید:

• Knockout: نبود آن گزینه را حذف می‌کند؛ مانند Eligibility قانونی، Export سفارش و محصول، درگاه عملیاتی یا پشتیبانی RTL.
• Must-have: باید تا Launch با Acceptance مشخص کار کند؛ مانند Variant، Return، Redirect و نقش کاربری.
• Should-have: ارزشمند است اما می‌تواند در Roadmap زمان‌دار قرار گیرد؛ مانند Loyalty پیشرفته.
• Won’t-now: آگاهانه خارج از Scope است تا Demo creep ایجاد نشود.

«اتصال به حسابداری» Requirement نیست. بنویسید: «پس از Paid/Refund، Order با Tax/Discount/Shipping و شناسه یکتا حداکثر در پنج دقیقه به سیستم X منتقل، Retry و Reconciliation روزانه داشته باشد.»

چهار خانواده راهکار را بشناسید

SaaS میزبانی‌شده

Vendor نرم‌افزار و زیرساخت پایه را اداره می‌کند و معمولاً Subscription می‌گیرد. مزیت آن کاهش کار زیرساختی است؛ نه حذف مسئولیت Merchant. شما همچنان مالک صحت Catalog، Access، Privacy، Policy، Integration و QA هستید. محدودیت Template/API/Export و تغییر قیمت یا Plan باید از ابتدا آزموده شود.

Open-source خودمیزبان

WooCommerce هسته‌ای Open-source روی WordPress است، اما فروشگاه «رایگان» نیست: Hosting، Domain، Theme/Extension، توسعه، Update، امنیت، Backup، Performance و Incident هزینه دارند. کنترل بیشتر تنها وقتی مزیت است که تیم بتواند آن را اداره کند. یک Plugin ناسازگار یا Update بدون Staging می‌تواند Checkout را متوقف کند.

Custom یا Headless

وقتی Pricing قراردادی B2B، Workflow تأیید، Omnichannel پیچیده یا Integration مزیت رقابتی است، Custom ممکن است توجیه داشته باشد. Headless نیز فقط جدا کردن Frontend از Commerce backend است؛ Complexity، Preview، SEO rendering، Deployment و Observability را افزایش می‌دهد. برای «ظاهر خاص» به‌تنهایی توجیه کافی نیست.

Marketplace/شبکه اجتماعی به‌عنوان Channel

برای کشف تقاضا و فروش مکمل مفیدند، ولی تغییر Algorithm/Policy/Access، کارمزد و مالکیت محدود داده ریسک Concentration می‌سازد. Product ID، Price، Stock و Order باید Source of truth مشخص داشته باشند تا چند Channel موجودی متناقض نسازند.

چشم‌انداز فعلی گزینه‌ها برای کسب‌وکار ایرانی

بررسی زیر در مرداد ۱۴۰۵ انجام شده است. قابلیت‌ها و Trialها ادعای صفحات رسمی Vendor هستند، نه تأیید مستقل Mindio؛ قیمت و Plan ممکن است تغییر کند. هر گزینه باید با داده و سناریوی خودتان در Pilot تأیید شود.

وجود نام یک Feature در Pricing page اثبات کیفیت نیست. «SEO»، «امنیت بالا»، «API» یا «پشتیبانی ۲۴/۷» باید به Control، Limit و SLA قابل اندازه‌گیری تبدیل شود. Screenshot سایت Vendor نیز جای Contract و Test را نمی‌گیرد.

Eligibility را قبل از Fit محصول بررسی کنید

ابتدا مطمئن شوید کسب‌وکار، کشور، نوع محصول، Payment و روش استفاده تحت Terms مجازند. Shopify صریحاً افراد و کسب‌وکارهای داخل ایران را از ساخت Account منع می‌کند؛ بنابراین مقایسه Theme و App آن برای فروشگاه مستقر در ایران، پیش از حل Eligibility، اتلاف وقت است.

این بخش مشاوره حقوقی نیست. قوانین، تحریم‌ها و قرارداد محصولات تغییر می‌کنند؛ Decision record باید تاریخ، منبع و Reviewer حقوقی/مالی مناسب داشته باشد. واسطه، VPN یا ثبت اطلاعات خلاف واقع، Eligibility پایدار نمی‌سازد.

Catalog را با نمونه سخت آزمایش کنید

یک Product ساده همه پلتفرم‌ها را شبیه هم نشان می‌دهد. Dataset آزمایشی باید لبه‌های واقعی شما را داشته باشد:

• Parent با رنگ/سایز و SKU مستقل برای هر Variant؛
• Attribute فارسی/لاتین، واحد، وزن و ابعاد؛
• محصول ساده، Bundle، فایل، خدمت یا اشتراک در Scope واقعی؛
• قیمت تومان، قیمت قبلی، تخفیف شرطی و Customer group؛
• Stock صفر، Backorder، Preorder و چند انبار؛
• تصویر بزرگ، Alt فارسی، ویدئو و سند؛
• سازگاری/مدل/گارانتی و «موجود در بسته»؛
• Import و Export با ID پایدار و خطای عمدی.

از Vendor بخواهید ۲۰ تا ۵۰ SKU لبه‌ای را Import، ویرایش گروهی، Export و دوباره Import کند. اختلاف Variant، تصویر، Taxonomy و ID را ثبت کنید. برای Product truth، Variant و Claimهای قابل‌اثبات، راهنمای سئو فروشگاه و کاتالوگ را مبنا بگذارید.

Order lifecycle مهم‌تر از صفحه محصول است

Demo معمولاً تا دکمه «خرید» می‌رود؛ عملیات واقعی بعد از آن شروع می‌شود. State machine حداقلی خودتان را بنویسید:

Created → Payment pending → Paid → Allocated → Packed → Shipped → Delivered → Kept

و شاخه‌های Payment failed / Cancelled / Partial shipment / Returned / Refunded / RTO را اضافه کنید.

«مدیریت سفارش دارد» تا وقتی State، Permission، Notification، Retry، Audit log و Reconciliation مشخص نیست، پاسخ کافی نیست.

هزینه کل مالکیت را برای ۲۴ ماه محاسبه کنید

رایگان بودن WooCommerce core، Trial رایگان SaaS یا دامنه هدیه، TCO فروشگاه را صفر نمی‌کند. دوره‌ای را انتخاب کنید که یک Renewal و رشد واقعی را ببیند.

TCO₂₄ = Setup + Subscription/Hosting + Theme/Extension + Transaction fees + Integration + Operations + Security/Backup + Support + Incident loss + Migration/Exit

سه سناریوی Base/Growth/Stress بسازید: تعداد SKU، Order، Staff، Storage، API call و Support ticket را تغییر دهید. قیمت Vendor را با Tax/ارزش افزوده، Renewal، افزایش Plan و هزینه Conversion تومان/ریال تاریخ‌دار کنید. برای Domain، Hosting، Renewal و Exit از راهنمای TCO دامنه و هاست استفاده کنید.

هزینه فرصت و Option value را فراموش نکنید

SaaS گران‌تر ممکن است Launch را دو ماه جلو بیندازد؛ Custom ارزان ظاهری ممکن است تیم را یک سال درگیر نگهداری کند. ارزش توان خروج، Export سالم و API مستند نیز Option value است. تصمیم را فقط با مبلغ Invoice نگیرید.

پرداخت، تسویه و Fraud را End-to-end تست کنید

پشتیبانی از نام یک درگاه کافی نیست. Merchant onboarding، نیازهای مجوز، Settlement، Reconciliation، Refund، Callback security، Amount unit و Incident support را با PSP و Vendor تأیید کنید.

داده حساس کارت را بی‌دلیل وارد Scope فروشگاه نکنید؛ Hosted payment و Tokenization می‌توانند Scope را کاهش دهند، اما Scriptهای صفحه Checkout همچنان Supply-chain risk دارند. اگر قرارداد یا بازار شما PCI DSS را لازم می‌کند، Inventory/Authorization/Integrity monitoring Script پرداخت را به‌طور رسمی بررسی کنید.

قانون و اطلاعات پیش از خرید باید در پلتفرم قابل اجرا باشند

قانون تجارت الکترونیکی ایران برای معامله با مصرف‌کننده، ارائه به‌موقع اطلاعات مؤثر بر تصمیم خرید و قواعدی برای انصراف/استثناها دارد. پلتفرم باید امکان نمایش هویت فروشنده، مشخصات کالا/خدمت، قیمت و هزینه‌ها، روش پرداخت/تحویل، شرایط فسخ/مرجوعی و مسیر شکایت را در جای قابل مشاهده بدهد.

این متن مشاوره حقوقی نیست؛ ماده، استثنا، مجوز صنفی/محصول و الزامات مالیاتی باید با متخصص و منبع جاری بررسی شوند. Badge یا نماد به‌تنهایی جای Policy، Security و عمل به تعهد را نمی‌گیرد. برای معماری شواهد، Review، امنیت و Return از راهنمای جلب اعتماد مشتری استفاده کنید.

UX، فارسی و Accessibility را روی Task بسنجید

Template زیبا ممکن است با نام محصول بلند فارسی، عدد لاتین، کد مدل، نیم‌فاصله یا Keyboard موبایل شکست بخورد. پنج Screenshot جای تست خرید نیست.

• RTL واقعی با Icon، Breadcrumb، Slider، Table و Bidi؛
• جست‌وجوی ی/ک، فاصله/نیم‌فاصله، غلط رایج و SKU لاتین؛
• نمایش روشن تومان/ریال در PDP، Cart، Checkout و Invoice؛
• آدرس ایران، استان/شهر، کدپستی، تلفن و Validation قابل اصلاح؛
• Keyboard، Focus، Label/Error، Zoom/Reflow و Target size؛
• Guest checkout و ورود/بازیابی بدون CAPTCHA مانع‌ساز؛
• Stock/Shipping/Return پیش از تعهد و بدون Surprise fee؛
• Network ضعیف، گوشی پایین‌رده و In-app browser.

WCAG ۲.۲ را Target فنی کنید، اما Conformance فقط با Audit خودکار ثابت نمی‌شود. Taskهای Search→PDP→Variant→Cart→Checkout→Payment failure→Retry و Return را با کاربران و فناوری کمکی مناسب بسنجید. راهنمای UX فروشگاه اینترنتی معیارهای Journey و Guardrail را کامل می‌کند.

کنترل‌های SEO فروشگاه را Feature عمومی نپذیرید

عبارت «SEO-friendly» Contract نیست. یک فروشگاه نمونه بسازید و Source/Rendered HTML/Crawl/GSC را روی این کنترل‌ها بررسی کنید:

Google برای Ecommerce روی URL، ساختار Navigation، Product data، Structured data و Pagination راهنمای مستقل دارد. Vendor نباید Rank یا Rich result را تضمین کند؛ کنترل فنی فقط Eligibility می‌سازد. Redirect و Canonical Migration را نیز پیش از قرارداد ثابت کنید، نه هنگام خروج.

Performance را با Template و Journey آزمایش کنید

Demo خالی روی Wi‑Fi سریع نماینده فروشگاه Production نیست. Dataset واقعی، Tagهای Marketing، Chat، Review، Font فارسی و تصاویر Catalog را روی Home/Category/PDP/Search/Cart/Checkout تست کنید.

SaaS مسئول زیرساخت پایه است، اما Third-party app، تصویر و Tag انتخابی شما می‌تواند Frontend را کند کند. در Self-hosted نیز Cache کردن Cart/Checkout بدون درک State، خطا می‌سازد. Performance budget باید به Template و Release gate وصل شود.

Reliability و Backup را با Restore ثابت کنید

«Backup روزانه» بدون RPO، RTO، Retention، Encryption، محل جدا و Restore test اطمینان نمی‌دهد. برای فروشگاه، Product، Order، Customer، Media، Config، Theme/Extension و Secret scopeهای متفاوتی دارند.

برای WooCommerce، فایل‌ها و Database هر دو لازم‌اند و Update باید پس از Backup روی Staging آزموده شود. برای SaaS نیز از Vendor بخواهید سطح Backup پلتفرم را از Export در اختیار Merchant جدا کند؛ این دو یک چیز نیستند.

امنیت را از SSL فراتر ببرید

HTTPS ضروری است اما اثبات «امنیت بالا» نیست. Threat model فروشگاه شامل Account takeover، Credential stuffing، Plugin/theme supply chain، Magecart/E-skimming، API abuse، Coupon fraud، Admin misuse، PII leak و DDoS است.

• MFA برای Admin و نقش‌های Least privilege؛
• Audit log برای Product/Price/Refund/Bank/Role؛
• Patch policy و Security advisory با Deadline؛
• Secret management و Rotation؛
• WAF/Rate limit/Bot و Fraud control متناسب؛
• Vulnerability reporting و Incident notification؛
• Subprocessor/Extension inventory؛
• Data minimization، Retention و حذف/Export.

در Self-hosted، یک Extension نامعتبر می‌تواند کل Trust boundary را گسترش دهد. در SaaS نیز App marketplace و Script سفارشی ریسک Third-party می‌سازند. Shared responsibility matrix را ضمیمه قرارداد کنید.

API، Webhook و Integration را با Failure طراحی کنید

Integration فقط «API دارد» نیست. Product/Stock/Price/Order/Customer/Refund/Shipment باید قرارداد، Version، Auth، Rate limit، Pagination، Idempotency، Retry، Webhook signature و Sandbox داشته باشند.

برای نوشتن Consumer-driven contract، Security و Reliability از راهنمای طراحی API وب استفاده کنید. Integration حیاتی باید Reconciliation دوره‌ای داشته باشد؛ Webhook موفق به‌تنهایی تضمین هم‌ترازی دو سیستم نیست.

Analytics و مالکیت داده را قبل از Launch حل کنید

Platform dashboard برای عملیات مفید است، اما تعریف Revenue، Customer و Attribution آن ممکن است با Finance/Analytics فرق کند. Tracking plan از View تا Kept order بسازید و Source of truth هر Entity را تعیین کنید.

• رویدادهای Ecommerce و transaction_id بدون Duplicate؛
• Refund/Cancel/Return و Delivered/Kept در Backend؛
• Consent و جلوگیری از PII در URL/Event؛
• UTM و Channel governance؛
• Export خام و اتصال Warehouse/BI؛
• Timezone، تومان/ریال و Tax/Shipping؛
• دسترسی Role-based و Retention؛
• Reconciliation Platform/Analytics/OMS/Finance.

Dashboard Vendor را به‌عنوان یکی از Viewها نگه دارید، نه تنها نسخه حقیقت. معماری Identity، Event و Reconciliation در راهنمای داده بازاریابی تکمیل شده است.

پشتیبانی را با Ticket آزمایشی و SLA بخرید

«پشتیبانی حرفه‌ای» باید به Scope و زمان تبدیل شود: چه Channelهایی، چه ساعت‌هایی، Severity چگونه تعریف می‌شود، First response با Resolution فرق دارد یا نه، Escalation و RCA چیست و Custom code/Third-party app در Scope هست یا نه.

در Trial یک سؤال مستنداتی، یک Bug قابل بازتولید و یک سناریوی Escalation بفرستید. کیفیت پاسخ، Ownership و Evidence مهم‌تر از تعداد کانال‌هاست.

RFP یک‌صفحه‌ای بسازید

برای Shortlist اولیه، سند صدصفحه‌ای لازم نیست. یک RFP کوتاه اما دقیق بفرستید:

1. مدل کسب‌وکار، بازار و هدف ۲۴ماهه؛
2. حجم فعلی/رشد SKU، Variant، Order، Staff و Traffic؛
3. ده سناریوی Must-have و Knockout؛
4. سیستم‌های Payment/Shipping/ERP/CRM/Analytics؛
5. نیازهای SEO، Accessibility، Performance و Security؛
6. مالکیت Domain/Data/Code و Export/Exit؛
7. SLA، Support، Backup/Restore و Incident؛
8. فرمت Quote شامل Setup، Recurring، Variable و Exit؛
9. Proof of Concept و Acceptance evidence؛
10. فرض‌ها، استثناها و Roadmap تعهدشده.

به Vendor اجازه دهید «پشتیبانی نمی‌شود» بگوید. پاسخ صادقانه با Workaround مالکیت‌پذیر بهتر از Yes مبهم است. پاسخ‌ها را در ماتریس هم‌سطح کنید؛ قیمت بدون Scope قابل مقایسه نیست.

Proof of Concept چهارده‌روزه اجرا کنید

Trial برای تغییر رنگ قالب نیست. یک Vertical slice کامل با داده Sanitized اجرا کنید:

اگر Trial هفت‌روزه است، Scope را کوچک کنید اما روز Exit را حذف نکنید. امکان «شروع رایگان» فقط کاهش هزینه Discovery است؛ نسخه رایگان دائمی یا Fit را ثابت نمی‌کند.

ماتریس امتیازدهی؛ ابتدا Knockout، سپس وزن

امتیاز ۱ تا ۵ را تعریف کنید: ۱=ناموجود، ۲=Workaround پرریسک، ۳=قبول پایه، ۴=قبول با Evidence، ۵=فراتر از نیاز با Evidence. Feature بی‌استفاده امتیاز اضافه ندارد. Knockout را با میانگین بالا پنهان نکنید.

سه مثال تصمیم برای بازار ایران

فروشگاه پوشاک خانگی با ۲۵۰ Parent

دو اپراتور، فروش در ایران، Variant رنگ/سایز و اتصال ساده ارسال دارد. Shortlist منطقی می‌تواند دو SaaS ایرانی باشد. Pilot باید جست‌وجوی فارسی، Variant stock، تخفیف، پرداخت ناموفق، تعویض سایز، Export و SEO control را بسنجد. اگر هر دو قبول‌اند، TCO/Support/Exit تعیین‌کننده می‌شود—نه تعداد Template.

فروشگاه قطعات با ۱۲هزار SKU و Fitment

سازگاری خودرو/مدل/سال، Price update از ERP و چند انبار دارد. Knockoutها API bulk، ID پایدار، Search/Filter قابل کنترل، Webhook سفارش و Performance Catalog هستند. WooCommerce با معماری و تیم قوی یا Commerce backend توسعه‌پذیر می‌تواند Shortlist شود؛ Site builder عمومی فقط پس از Proof این سناریو.

تولیدکننده B2B با قیمت قراردادی

Quote، حد اعتبار، نقش خریدار/تأییدکننده و Invoice خاص دارد. اگر این Workflow مزیت اصلی است، Custom module یا پلتفرم B2B توجیه بیشتری دارد. بااین‌حال Authentication، Catalog و CMS را از صفر نسازید مگر Gap اثبات شود. Phase اول می‌تواند Catalog/Lead باشد و Checkout قراردادی بعد از یادگیری بیاید.

Migration را روز انتخاب طراحی کنید

همه پلتفرم‌ها روزی تغییر می‌کنند: قیمت، مالکیت، نیاز، تیم یا Vendor. Exit plan نشانه بدبینی نیست؛ کنترل ریسک است.

پیش از Cutover، نقشه Old→New، Canonical، Sitemap، Internal link و ۳۰۱ مستقیم بسازید؛ Passwordها را منتقل نکنید و Account migration امن طراحی کنید. فرایند فنی در راهنمای ریدایرکت و مهاجرت URL آمده است.

بندهای قرارداد که نباید مبهم بمانند

• Scope، Deliverable، فرض‌ها و Acceptance قابل آزمون؛
• مالکیت Domain، Data، Design، Code و Customization؛
• Plan/Limit، قیمت Renewal، کارمزد و روش تغییر قیمت؛
• Availability، Support severity، Response، Escalation و RCA؛
• Security، Incident notification، Subprocessor و Patch؛
• Backup، RPO/RTO، Retention و Restore test؛
• Privacy، Purpose، Retention، حذف و تحویل داده؛
• API version، Deprecation و Integration support؛
• Termination، مهلت Export، فرمت، هزینه و حذف نهایی؛
• Handover، Documentation، Training و Exit assistance.

Roadmap شفاهی Feature نیست. اگر Requirement برای Launch حیاتی است، یا اکنون با Evidence وجود دارد یا تعهد زمان‌دار/جریمه/راه خروج در قرارداد می‌خواهد.

نشانه‌های هشدار در فروشگاه‌ساز و پیشنهاد اجرا

برنامه ۳۰/۶۰/۹۰روزه انتخاب و راه‌اندازی

روز ۱ تا ۳۰: Discovery و Shortlist

• Commerce brief، Outcome و سناریوی ۲۴ماهه را تصویب کنید.
• Knockout/Must/Should و Dataset لبه‌ای بسازید.
• Eligibility، قانون، Payment، Data و Domain را Gate کنید.
• RFP هم‌سطح برای حداکثر سه گزینه بفرستید.
• TCO سه‌سناریویی و Risk register اولیه تهیه کنید.

روز ۳۱ تا ۶۰: Pilot و قرارداد

• Vertical slice چهارده‌روزه روی دو Finalist اجرا کنید.
• UX/RTL/SEO/Performance/Security/API/Support/Exit را با Evidence امتیاز دهید.
• Gap و Workaround را Owner/Cost/Deadline بدهید.
• Reference call را با سؤال Incident و Exit انجام دهید.
• Contract، SLA، Data/Code ownership و Acceptance را نهایی کنید.

روز ۶۱ تا ۹۰: Build، Launch و Stabilize

• Catalog migration و Integration را با Reconciliation اجرا کنید.
• Staging، Backup/Restore، Role، Consent و Incident runbook را Pass کنید.
• SEO URL map، Analytics و Synthetic journey را پیش از Cutover تأیید کنید.
• Soft launch با Order cap و War room انجام دهید.
• ۳۰ روز Hypercare، Error budget و Post-launch review داشته باشید.

چک‌لیست تصمیم نهایی

• Business outcome و Commerce model روشن‌اند.
• Eligibility ایران، Category و Payment کتبی تأیید شده‌اند.
• Catalog/Variant/Stock/Order/Return با داده واقعی Pass شده‌اند.
• تومان/ریال، فارسی/RTL، Mobile و Accessibility آزموده شده‌اند.
• URL/Canonical/Redirect/Crawl/Schema کنترل‌پذیرند.
• Field/Lab/Load و Journey بحرانی Baseline دارند.
• MFA/Role/Audit/Patch/Incident و Third party مشخص‌اند.
• Backup با Restore، RPO و RTO تأیید شده است.
• API/Webhook/Export/ID/Reconciliation Contract دارند.
• Data ownership، Consent، Retention و حذف روشن‌اند.
• TCO ۲۴ماهه Base/Growth/Stress و Exit محاسبه شده است.
• SLA/Support/Acceptance/Rollback در قرارداد آمده‌اند.
• دامنه و حساب‌های اصلی متعلق به کسب‌وکارند.
• Migration و Exit rehearsal پیش از خرید انجام شده است.

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

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

پاسخ ثابت ندارد. سازیتو، پرتال و وبزی Positioning و عمق متفاوتی دارند؛ ادعاهای صفحه رسمی را با Catalog، Checkout، Return، SEO، API، Support و Export خودتان در Pilot بسنجید. گزینه‌ای برنده است که Knockoutها را Pass و TCO/ریسک بهتری داشته باشد.

آیا WooCommerce واقعاً رایگان است؟

هسته WooCommerce Open-source و رایگان است، اما فروشگاه عملی هزینه Domain، Hosting، Theme/Extension، توسعه، امنیت، Update، Backup، Performance و Support دارد. کنترل بیشتر بدون Owner فنی می‌تواند از SaaS پرهزینه‌تر شود.

آیا Shopify برای فروشگاه مستقر در ایران مناسب است؟

طبق صفحه رسمی جاری Shopify، ایران Unsupported است و افراد/کسب‌وکارهای داخل این مناطق مجاز به ساخت Account نیستند. این راهنما دورزدن، حساب واسطه یا اطلاعات خلاف واقع را توصیه نمی‌کند؛ گزینه‌ای انتخاب کنید که Eligibility قانونی و پایدار داشته باشد.

آیا بعداً می‌توان فروشگاه را به پلتفرم دیگری منتقل کرد؟

بله، اما کیفیت Export و ID، Media، Order history، Customer consent، URL و Featureهای اختصاصی هزینه را تعیین می‌کنند. پیش از خرید، Full export و Round-trip sample بگیرید و قرارداد Exit/مهلت تحویل/حذف داده را روشن کنید.

چند روز برای تست فروشگاه‌ساز کافی است؟

عدد ثابت نیست، اما هفت تا چهارده روز برای یک Vertical slice محدود معمولاً نقطه شروع است. شرط اصلی پوشش چرخه کامل Import→Search→Checkout→Payment failure/retry→Delivery/Return→Analytics→Export است؛ نه تعداد روز یا زمان طراحی قالب.

جمع‌بندی: بهترین پلتفرم، کم‌ریسک‌ترین تصمیم قابل خروج است

نام برند، تعداد Template یا رایگان بودن هسته نمی‌گوید کدام سایت‌ساز برای شما مناسب است. ابتدا Commerce brief و Knockoutها را بسازید؛ سپس SaaS ایرانی، WooCommerce یا Custom را با Dataset واقعی، TCO ۲۴ماهه، Security/SEO/UX/API و روز Exit مقایسه کنید.

دو Finalist را نگه دارید، یک Vertical slice را تا سفارش و مرجوعی اجرا کنید، Full export بگیرید و Support را هنگام خطا بسنجید. تصمیم خوب پلتفرمی است که امروز فروش را ممکن کند، فردا رشد را تحمل کند و روز جدایی، Domain، Data و مشتری را برای خود کسب‌وکار نگه دارد.

منابع رسمی و صفحات محصول

• سازیتو: صفحه رسمی محصول و قابلیت‌های اعلامی
• سازیتو: صفحه رسمی Plan و تعرفه
• پرتال: صفحه رسمی محصول و قابلیت‌های اعلامی
• پرتال: صفحه رسمی Plan و تعرفه
• وبزی: صفحه رسمی محصول و قابلیت‌های اعلامی
• WooCommerce: مستندات رسمی پلتفرم و Migration
• WooCommerce: امنیت، داده و Payment gateway
• Shopify: کشورهای و مناطق پشتیبانی‌نشده
• Google Search Central: Ecommerce SEO best practices
• W3C: Web Content Accessibility Guidelines 2.2
• PCI SSC: Payment page security و E-skimming
• WIPO Lex: قانون تجارت الکترونیکی ایران