FutureForgeFutureForge

خدمات FutureForge

  • طراحی و ساخت محصولاز شناخت نیاز تا انتشار محصول، یک مسیر روشن پیش رو دارید.
  • توسعه فول‌استکوب‌اپلیکیشن، API و داده را هماهنگ و یکپارچه توسعه دهید.
  • ممیزی مهندسیپیش از هزینه‌ی بیشتر، از وضعیت واقعی محصول‌تان باخبر شوید.
  • مشاوره معماریپیش از یک تصمیم فنی پرهزینه، گزینه‌ها را درست بسنجید.
  • زیرساخت و استقرارمحصول را با خیال راحت منتشر کنید و پایدار نگه دارید.
  • هوش مصنوعی در محصولهوش مصنوعی را فقط جایی به کار می‌گیریم که مسئله‌ای را حل کند.
نمونه‌کارهایادداشت‌هاقیمت‌گذاریدرباره ما
شروع گفتگو
  1. خانه
  2. /یادداشت‌ها
  3. /یادداشت‌ها
FutureForge

استودیوی مهندسی محصول — طراحی، ساخت و استقرار نرم‌افزار.

خدمات

طراحی سایت با وردپرستوسعه اختصاصیمهندسی محصولزیرساخت و استقرارمشاوره معماریهوش مصنوعی در محصول

راهنمای انتخاب

یادداشت‌هاقیمت‌گذاریتخمین هزینه پروژهمقایسه روش‌هانمونه‌کارهادرباره ماتماس

ارتباط

hello@futureforge.ir

ایده‌ای برای ساخت دارید؟

نیازتان را مطرح کنید تا درباره مسیر توسعه و قدم بعدی صحبت کنیم.

شروع گفتگو

© 2026 FutureForge. همه حقوق محفوظ است.

حریم خصوصیشرایط استفاده
خانهنمونه‌کارشروعتماس
مهندسی محصول

طراحی کاتالوگ فروشگاه اینترنتی: تنوع، ویژگی و موجودی

سا
سهیل ابراهیم‌پور
·۱ آبان ۱۴۰۵·7 دقیقه مطالعه
کاتالوگ محصولتنوع محصولSKUفروشگاه اینترنتیProductGroup
توسعه‌دهنده در حال طراحی نمودار مدل داده برای کاتالوگ فروشگاه

محصول، تنوع و موجودی را جدا مدل کنید. بر پایهٔ مستند ProductGroup گوگل و توصیه‌های عملی دربارهٔ ویژگی مشترک و اختصاصی و فیلتر.

مدل‌سازی کاتالوگ، بخشی از فروشگاه است که اگر اشتباه شروع شود، فیلتر، موجودی و سئو را با هم خراب می‌کند. این مقاله یک مدل ساده را پیشنهاد می‌دهد که با مستندات Google برای تنوع محصول هم‌خوان است. ساختار جدول‌ها و فیلترها توصیهٔ نویسنده است و تنها بخش تنوع منبع رسمی دارد. روی هیچ پایگاه دادهٔ خاص هم تعهد نداریم.

سه مفهوم: محصول، تنوع، موجودی

Google بین «گروه محصول» و «تنوع» فرق می‌گذارد: پوشاک، کفش، مبلمان و لوازم الکترونیکی با اندازه، رنگ، جنس یا طرح متفاوت فروخته می‌شوند و برای گروه‌بندی‌شان از ProductGroup با variesBy، hasVariant و productGroupID استفاده می‌شود. همین تمایز در دیتابیس هم کارآمد است: محصول والد (نام، برند، توضیح)، تنوع (SKU قابل‌فروش) و موجودی که به SKU وصل است، نه به والد. (جداسازی موجودی روی SKU توصیهٔ نویسنده است.)

ویژگی مشترک و اختصاصی

طبق Google، ProductGroup اجازه می‌دهد ویژگی‌های مشترک همهٔ تنوع‌ها مثل برند را یک‌جا بگذارید و فقط ویژگی‌های تعیین‌کنندهٔ تنوع را روی هر تنوع بیاورید؛ این کار تکرار را کم می‌کند. توصیهٔ نویسنده برای جدول‌بندی: ویژگی‌هایی که همهٔ محصولات دارند (نام، برند، وزن) ستون ثابت باشند؛ ویژگی‌های دستهٔ خاص (مثلاً «جنس بدنه») در ساختار انعطاف‌پذیر ولی دارای تعریف دسته مثل جدول ویژگی یا JSON تعریف‌شده نگه داشته شوند. هر دو راه مزیت و هزینهٔ پرس‌وجو دارند؛ این مقاله مقایسهٔ آن‌ها را انجام نداده است.

تنوع: یک صفحه یا چند صفحه؟

مستند Google دو الگوی رایج را نام می‌برد: تک‌صفحه‌ای که تنوع‌ها با پارامتر کوئری بدون بارگذاری مجدد انتخاب می‌شوند، و چندصفحه‌ای که هر تنوع صفحهٔ خودش را دارد. انتخاب بین این دو روی URL، فیلتر و موجودی اثر دارد؛ ساختار markup هر کدام در همان مستند مثال دارد. این‌که کدام برای فروشگاه شما بهتر است، به تعداد تنوع‌ها و نیاز سئو بستگی دارد (توصیهٔ نویسنده).

محصول والد، تنوع‌ها و موجودی
نمودار مفهومی.

فیلترهای قابل‌استفاده

فیلتر باید از ویژگی‌های ساخت‌یافته ساخته شود، نه متن آزاد. هر ویژگی را با نوع (عدد، فهرست مقدار، بله/خیر) و واحد تعریف کنید تا فیلتر «گسترهٔ قیمت» یا «رنگ» ممکن شود. فیلترهایی که نتیجهٔ صفر می‌دهند را پنهان یا کم‌رنگ کنید. این فهرست توصیهٔ نویسنده است؛ دربارهٔ سئوی صفحات فیلتر باید به مستندات Google برای ناوبری با فیلتر مراجعه کنید.

ProductGroup در داده ساختاریافتهٔ Google

مستند «Product variant structured data» گوگل (خوانده‌شده در ۱۹ اکتبر ۲۰۲۶) می‌گوید محصولاتی مثل پوشاک، کفش، مبلمان و چمدان در تنوع‌های مختلف (اندازه، رنگ، جنس، الگو) فروخته می‌شوند. برای اینکه گوگل بفهمد کدام محصولات تنوع‌های یک محصول والد هستند، کلاس ProductGroup با ویژگی‌های variesBy، hasVariant و productGroupID در کنار نشانه‌گذاری Product استفاده می‌شود. ویژگی‌های مشترک (برند، نظرها) در سطح ProductGroup و ویژگی‌های متمایزکننده در سطح هر Product می‌آیند که تکرار را کم می‌کند. تنها ویژگی الزامی ProductGroup برابر name است و نام هر تنوع باید مشخص‌تر باشد، مثلاً «کت زمستانی – سبز، سایز کوچک» (مثال خود مستند به انگلیسی).

تک‌صفحه‌ای یا چندصفحه‌ای: اثر بر نشانه‌گذاری

مستند گوگل دو رویکرد را از هم جدا می‌کند. در طراحی تک‌صفحه‌ای همهٔ تنوع‌ها روی یک صفحه با پارامترهایی مثل ?size=small&color=green انتخاب می‌شوند، تصویر و قیمت و موجودی بدون بارگذاری مجدد عوض می‌شود و نشانه‌گذاری صفحه با انتخاب کاربر تغییر پویا نمی‌کند؛ مثال مستند، تنوع‌ها را با hasVariant زیر ProductGroup می‌گذارد. در طراحی چندصفحه‌ای هر تنوع آدرس خودش را دارد و مستند صریحاً می‌گوید تعریف کامل ProductGroup باید در هر صفحهٔ تنوع تکرار شود و ProductGroup آدرس canonical ندارد چون یک آدرس واحد آن را نمایندگی نمی‌کند. نتیجهٔ عملی: انتخاب بین این دو رویکرد باید پیش از طراحی قالب انجام شود (برداشت نویسنده).

الگوی مدل‌سازی داده (پیشنهاد نویسنده)

الگوی جداول کاتالوگ برای تنوع
موجودیتفیلدهای نمونهیادداشت
محصول والدشناسهٔ گروه، نام، برند، توضیح، دستهمرجع productGroupID
گزینهنام گزینه (رنگ، اندازه) و مقادیر مجازمرجع variesBy
تنوع (SKU)sku، مقادیر گزینه، قیمت، تصویر، آدرسیک ردیف برای هر ترکیب فروختنی
موجودیsku، انبار، تعداد قابل‌فروشروی SKU نه محصول والد

موجودی و قیمت باید روی سطح SKU نگهداری شود؛ ترکیب‌های ناممکن (مثلاً رنگی که در یک سایز تولید نمی‌شود) باید ردیف نداشته باشند تا کاربر به گزینهٔ ناموجود هدایت نشود.

آزمون و انتشار نشانه‌گذاری

مستند گوگل مراحل را این‌گونه می‌دهد: ویژگی‌های الزامی را اضافه کنید، کد را با Rich Results Test اعتبارسنجی کنید، چند صفحه را منتشر و با URL Inspection بررسی کنید که گوگل صفحه را چگونه می‌بیند، مطمئن شوید صفحه با robots.txt، برچسب noindex یا نیاز به ورود مسدود نیست و در نهایت نقشهٔ سایت را ارسال کنید؛ ممکن است چند روز تا خزش دوباره طول بکشد. توجه کنید نشانه‌گذاری صرفاً شما را برای نمایش اطلاعات تنوع واجد شرایط می‌کند و نمایش تضمین‌شده نیست.

مثال ساختگی: یک پالتو با دو رنگ

فروشگاهی ساختگی پالتویی دارد با دو رنگ و دو سایز. اگر تنوع‌ها روی یک صفحه انتخاب می‌شوند، یک ProductGroup با نام «پالتو پشمی» و variesBy برابر اندازه و رنگ و سه یا چهار Product زیر آن (فقط ترکیب‌های موجود) تعریف می‌شود. اگر هر رنگ صفحهٔ جدا دارد، تعریف ProductGroup در هر دو صفحه تکرار می‌شود. در هر دو حالت، موجودی هر SKU جدا ثبت می‌شود. این مثال تنها برای توضیح ساختار است و روی ابزار آزمایش اجرا نشده.

اشتباه‌های رایج کاتالوگ تنوع‌دار

  • نگهداری موجودی روی محصول والد به‌جای SKU.
  • ساختن صفحهٔ جدا برای هر تنوع بدون تعریف تکرار ProductGroup.
  • نام یکسان برای همهٔ تنوع‌ها که گزینهٔ انتخاب‌شده را مشخص نمی‌کند.
  • نمایش ترکیب‌های ناموجود به‌صورت قابل‌انتخاب بدون توضیح.

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

  • آیا هر رنگ باید SKU جدا داشته باشد؟ اگر قابل‌فروش و قابل‌موجودی جدا است بله.
  • آیا ویژگی‌ها را همه فیلتر کنیم؟ فقط آنچه خریدار برای مقایسه به آن نیاز دارد.
  • چه کسی کاتالوگ را به‌روز می‌کند؟ مالک مشخص و فرایند تأیید لازم است.
  • آیا نشانه‌گذاری Product روی همهٔ صفحات لازم است؟ فقط صفحه‌هایی که واقعاً محصول قابل‌خرید را نمایش می‌دهند.

پاسخ‌ها جمع‌بندی نویسنده‌اند و باید با سیاست فروشگاه و راهنمای رسمی ابزارها تطبیق داده شوند.

گام‌های پیشنهادی راه‌اندازی کاتالوگ

ابتدا فهرست گزینه‌ها (رنگ، اندازه) و مقادیر مجاز را برای چند محصول نمونه بنویسید و ترکیب‌های واقعاً فروختنی را مشخص کنید. سپس مدل داده را با یک محصول پیاده کنید و موجودی را روی SKU ثبت کنید. بعد قالب صفحه (تک‌صفحه‌ای یا چندصفحه‌ای) و آدرس‌ها را مشخص و نشانه‌گذاری را اضافه کنید. سپس با Rich Results Test و URL Inspection چند صفحه را بررسی کنید و پس از اطمینان، بقیهٔ کاتالوگ را وارد کنید. در هر مرحله یک نفر مسئول صحت داده باشد و تغییرات بزرگ با فایل نمونه آزمایش شود تا ورود انبوه خطا نسازد. این ترتیب پیشنهاد نویسنده است.

چک‌لیست

  1. محصول والد و تنوع جدا تعریف شده‌اند.
  2. موجودی روی SKU است و جداگانه ثبت می‌شود.
  3. ویژگی‌ها نوع و واحد دارند.
  4. الگوی تنوع (تک‌صفحه یا چندصفحه) آگاهانه انتخاب شده است.
  5. برای تصمیم‌های معماری بزرگ‌تر، انتخاب معماری اپلیکیشن وب را ببینید.

منابع و مراجع

  • Product variant structured data (ProductGroup, Product) — Google Search Central.

نویسنده

سا

سهیل ابراهیم‌پور بنیان‌گذار FutureForge است. روی طراحی محصول، معماری و استقرار نرم‌افزار سفارشی کار می‌کند.

یادداشت‌های مرتبط

یادداشت‌های مرتبط

دسته‌بندی‌ها

خدمات مرتبط

از یادداشت تا پروژه

اگر با مسئله‌ای شبیه این روبه‌رو هستید، درباره‌ی شرایط پروژه‌تان با هم صحبت کنیم.

برای انتخاب مسیر فنی پروژه‌تان کمک می‌خواهید؟

از مسئله و محدودیت‌هایتان بگویید؛ اگر بتوانیم همراهی‌تان کنیم، برای گفت‌وگو هماهنگ می‌کنیم.

سهیل ابراهیم‌پور
یادداشت‌ها
baseline قبل از بازطراحی سایت: نرخ تبدیل، سرعت و تجربهٔ کاربر
تحویل طراحی به توسعه: چه مشخصاتی جلوی بازکاری را می‌گیرد؟
فرم تماس سایت: چه چیزی اعتماد کاربر را بیشتر می‌کند؟
تست دسترس‌پذیری صفحه‌کلید: پروتکل دستی بر پایهٔ WCAG 2.2
توکن‌های طراحی چیستند؟ هم‌نام‌سازی Figma و کد

مهندسی محصول

baseline قبل از بازطراحی سایت: نرخ تبدیل، سرعت و تجربهٔ کاربر

۱ آبان ۱۴۰۵

مهندسی محصول

تحویل طراحی به توسعه: چه مشخصاتی جلوی بازکاری را می‌گیرد؟

۳۰ مهر ۱۴۰۵

مهندسی محصول

فرم تماس سایت: چه چیزی اعتماد کاربر را بیشتر می‌کند؟

۲۹ مهر ۱۴۰۵

مهندسی محصول

تست دسترس‌پذیری صفحه‌کلید: پروتکل دستی بر پایهٔ WCAG 2.2

۲۹ مهر ۱۴۰۵

مهندسی محصول

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

۲۸ مهر ۱۴۰۵
همه یادداشت‌ها254
معماری نرم‌افزار15
واژه‌نامه37
عملیات و استقرار87
مهندسی محصول102
راهنمای وب13
طراحی و ساخت محصول
توسعه فول‌استک
ممیزی مهندسی
مشاوره معماری
زیرساخت و استقرار
شروع گفتگو
ابزارهای رایگان
شروع گفتگو