اسکیما محصول برای فایل دانلودی؛ داده‌های ضروری صفحه خرید

اسکیما محصول برای فایل دانلودی راهی است برای اینکه نام محصول، قیمت جاری، ارز، وضعیت عرضه و نشانی صفحه به‌شکل ماشین‌خوان در اختیار موتور جست‌وجو قرار گیرد. این نشانه‌گذاری نباید جای محتوای صفحه را بگیرد یا نشانی محرمانه دریافت محتوا را افشا کند؛ وظیفه آن توصیف همان پیشنهاد خریدی است که بازدیدکننده روی صفحه می‌بیند. این راهنما بر اساس اسناد در دسترس تا ۱۵ اوت ۲۰۲۶ تهیه شده است.

اسکیما محصول برای فایل دانلودی دقیقاً چه کاری انجام می‌دهد؟

Product هویت محصول را توصیف می‌کند و Offer شرایط عرضه آن را در بر می‌گیرد. در واژگان Product در Schema.org، ویژگی offers می‌تواند یک پیشنهاد ارائه یا خرید را به محصول متصل کند. بنابراین دیجیتالی‌بودن محصول مانع توصیف آن با این دو نوع نیست؛ اما استفاده درست از واژگان Schema.org به‌تنهایی به معنی احراز همه شرایط نمایش‌های تجاری گوگل نیست.

باید میان دو هدف مرتبط تفاوت گذاشت. طبق راهنمای Product snippet گوگل، صفحه‌ای که روی یک محصول مشخص تمرکز دارد، با داشتن name و دست‌کم یکی از offers، review یا aggregateRating می‌تواند برای نتیجه محصول غنی واجد شرایط شود. در مقابل، راهنمای Merchant listing الزامات گسترده‌تری دارد و صفحه باید امکان خرید مستقیم همان محصول را فراهم کند.

برای عرضه‌های دانلودی نباید «امکان توصیف با Product» را با «تضمین حضور در همه تجربه‌های Shopping» یکی دانست. صفحه راهنمای گزارش‌های Shopping در Search Console توضیح می‌دهد که بخش Merchant opportunities برای سایت‌های واجد شرایط عرضه کالاهای فیزیکی ظاهر می‌شود؛ در عین حال، گزارش Product snippets ممکن است پس از شناسایی داده محصول در دسترس باشد. نتیجه عملی این است که ابتدا نشانه‌گذاری صادقانه و معتبر بسازید و نوع نمایش نهایی را به ارزیابی گوگل واگذار کنید.

چه اطلاعاتی باید روی صفحه و در داده ساختاریافته باشد؟

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

• نام یکتا: عنوان داخل Product.name با عنوان اصلی و قابل مشاهده صفحه یکسان باشد؛ پسوند تبلیغاتی یا عبارتی که در صفحه وجود ندارد به آن اضافه نشود.
• توضیح روشن: نوع محتوا، موضوع، قالب و محدوده کلی استفاده توضیح داده شود. description خلاصه همین متن است، نه محلی برای ادعاهای تازه.
• تصویر نماینده: تصویر جلد، پیش‌نمایش یا موکاپی که واقعاً محصول را نمایندگی می‌کند. در Merchant listing، گوگل image را از ویژگی‌های ضروری Product می‌داند و تأکید دارد نشانی تصویر قابل خزش و نمایه‌سازی باشد.
• قیمت فعال: مبلغی که کاربر اکنون برای همان گزینه می‌پردازد، بدون جداکننده هزارگان در مقدار ماشین‌خوان. قیمت خط‌خورده یا مبلغ یک بسته متفاوت نباید به‌عنوان قیمت جاری ثبت شود.
• ارز: priceCurrency با کد سه‌حرفی ISO 4217 نوشته شود؛ برای نمونه IRR. واحد قابل مشاهده صفحه نیز باید با همین مقدار سازگار باشد.
• وضعیت عرضه: برای محتوایی که فقط آنلاین ارائه می‌شود، https://schema.org/OnlineOnly می‌تواند از نظر معنایی مناسب باشد. اگر خرید موقتاً بسته شده است، وضعیت واقعی مانند OutOfStock یا Discontinued را انتخاب کنید.
• نشانی پیشنهاد: Offer.url باید نشانی عمومی و پایدار همان صفحه محصول یا مرحله‌ای باشد که خرید همان پیشنهاد در آن انجام می‌شود؛ نه نشانی فایل، پنل کاربر یا لینک موقت دریافت.

مواردی مانند شناسه داخلی sku، نام ناشر یا برند، دسته‌بندی و ویژگی‌های فنی نیز مفیدند. قالب محتوا، نسخه، زبان، حجم تقریبی یا نوع مجوز را می‌توان با additionalProperty و اشیای PropertyValue توصیف کرد، به شرط آنکه در صفحه هم دیده شوند. این ویژگی‌ها لزوماً جزئی از ظاهر غنی گوگل نیستند، اما معنای محصول را برای مصرف‌کنندگان داده روشن‌تر می‌کنند.

چه چیزی نباید در اسکیما افشا شود؟

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

نمونه JSON-LD برای Product و Offer

سناریوی زیر یک بسته آموزشی فرضی با قیمت ۲٬۹۰۰٬۰۰۰ ریال است که فقط به‌صورت آنلاین عرضه می‌شود. نام، قیمت، قالب PDF، زبان و تصویر فرض‌شده باید عیناً یا با همان معنا در محتوای قابل مشاهده صفحه حضور داشته باشند. کد را با داده واقعی و نشانی‌های قطعی سایت جایگزین کنید.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://example.com/products/financial-guide#product",
  "name": "راهنمای کاربردی تحلیل صورت‌های مالی",
  "description": "مجموعه آموزشی فارسی در قالب PDF برای آشنایی با تحلیل صورت‌های مالی.",
  "image": [
    "https://example.com/images/financial-guide-cover.jpg"
  ],
  "sku": "DG-FIN-101",
  "category": "محتوای آموزشی دیجیتال",
  "additionalProperty": [
    {
      "@type": "PropertyValue",
      "name": "قالب",
      "value": "PDF"
    },
    {
      "@type": "PropertyValue",
      "name": "زبان",
      "value": "فارسی"
    }
  ],
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/financial-guide",
    "price": 2900000,
    "priceCurrency": "IRR",
    "availability": "https://schema.org/OnlineOnly"
  }
}

در مستند Merchant listing گوگل که در ۷ ژوئیه ۲۰۲۶ به‌روزرسانی شده، name، image و offers برای Product و قیمت و ارز برای Offer از داده‌های ضروری این تجربه معرفی شده‌اند. availability توصیه‌شده است، اما افزودن آن برای صفحه خرید عملی است، زیرا وضعیت عرضه را صریح می‌کند.

priceValidUntil را فقط زمانی اضافه کنید که پایان اعتبار قیمت واقعاً مشخص است. تاریخی که گذشته باشد می‌تواند مانع نمایش قیمت در Product snippet شود. برای قیمت دائمی، ساختن یک تاریخ صوری و تمدید دوره‌ای آن ارزشی ندارد. اگر چند ارز ارائه می‌کنید، راهنمای گوگل پیشنهاد می‌کند برای هر ارز نشانی متمایزی داشته باشید.

اصل حیاتی: داده پنهان نباید با صفحه اختلاف داشته باشد

طبق دستورالعمل عمومی داده‌های ساختاریافته گوگل که در ۱۰ ژوئیه ۲۰۲۶ به‌روزرسانی شده، نباید اطلاعاتی را نشانه‌گذاری کرد که برای خواننده صفحه قابل مشاهده نیست. این قاعده فقط درباره نام و توضیح نیست؛ قیمت، ارز، وضعیت عرضه، امتیاز و تعداد نقدها نیز باید با صفحه منطبق باشند.

فرض کنید کارت بالای صفحه قیمت ۲٬۹۰۰٬۰۰۰ ریال را نشان می‌دهد، اما افزونه سئو هنوز قیمت قبلی ۲٬۴۰۰٬۰۰۰ ریال را در JSON-LD تولید می‌کند. حتی اگر کد از نظر نحوی صحیح باشد، داده ارائه‌شده نماینده پیشنهاد جاری نیست. راه‌حل پایدار این است که متن صفحه، سبد خرید و اسکیما همگی قیمت را از یک منبع داده مشترک بخوانند.

همین کنترل برای وضعیت عرضه لازم است. محصولی که دکمه خرید آن غیرفعال شده نباید همچنان InStock یا OnlineOnly داشته باشد. اگر دسترسی فقط برای گروهی از کاربران، دوره‌ای مشخص یا یک نوع مجوز فراهم است، شرایط باید نزدیک قیمت توضیح داده شود؛ اسکیما نباید یک پیشنهاد عمومی‌تر از پیشنهاد واقعی بسازد.

خطاهای رایج در داده ساختاریافته محصول دانلودی

نشانه‌گذاری صفحه فهرست به‌عنوان یک محصول

گوگل نتایج غنی Product را برای صفحه‌ای پشتیبانی می‌کند که بر یک محصول یا چند گونه از همان محصول تمرکز دارد. صفحه دسته‌بندی شامل چند محصول مستقل، محل مناسبی برای قرار دادن یک Product واحد با ارزان‌ترین قیمت موجود نیست. هر محصول باید صفحه مشخص و داده متناظر خود را داشته باشد.

قیمت ناهماهنگ یا مبهم

قرار دادن عبارت‌هایی مانند «از ۲۹۰ هزار» در price معتبر نیست؛ این ویژگی عدد فعال را می‌خواهد. تعریف Offer در Schema.org نیز استفاده از نقطه برای اعشار، پرهیز از جداکننده‌های نمایشی و درج ارز در ویژگی جداگانه را توصیه می‌کند. اگر چند مجوز با قیمت متفاوت دارید، ابتدا ساختار صفحه و نشانی هر گزینه را روشن کنید و سپس الگوی مناسب گونه‌ها یا پیشنهادها را انتخاب کنید.

امتیاز و نقد ساختگی

نوشتن یک امتیاز دلخواه در aggregateRating برای جلب توجه، یا افزودن Review بدون نظر واقعی کاربر، با دستورالعمل‌های کیفیت سازگار نیست. تعداد نقد و میانگین امتیاز باید از نقدهای واقعی و قابل مشاهده محاسبه شود. اگر هنوز سامانه معتبر ثبت نظر ندارید، حذف این ویژگی‌ها بهتر از تولید داده ظاهراً کامل است.

تصور تضمین نمایش ریچ‌ریزلت

عبور از آزمون فنی فقط نشان می‌دهد داده برای یک قابلیت پشتیبانی‌شده قابل پردازش است. گوگل صریحاً می‌گوید حتی نشانه‌گذاری صحیح، نمایش نتیجه غنی را تضمین نمی‌کند؛ ارتباط با محتوای اصلی، کیفیت صفحه، دسترسی خزنده و تصمیم الگوریتم نمایش نیز مؤثرند. اسکیما ابزار توضیح محتواست، نه فرمانی برای شکل نتیجه جست‌وجو.

تولید جداگانه چند بلوک متناقض

قالب فروشگاه، افزونه سئو و کد سفارشی ممکن است هر سه Product بسازند. اگر شناسه، قیمت یا وضعیت این بلوک‌ها متفاوت باشد، موتور جست‌وجو با چند روایت روبه‌رو می‌شود. کد نهایی رندرشده را بررسی کنید و برای موجودیت اصلی فقط یک منبع مسئول تعیین کنید.

چک‌لیست پیاده‌سازی و کنترل

1. برای هر محصول یک صفحه عمومی، قابل خزش و متمرکز بر همان محصول انتخاب کنید.
2. نام، توضیح، تصویر پیش‌نمایش، قیمت، واحد پول، وضعیت عرضه، قالب و شرایط مجوز را به‌شکل قابل مشاهده در صفحه بنویسید.
3. یک Product بسازید و Offer همان پیشنهاد فعال را داخل offers قرار دهید.
4. قیمت را با رقم‌های لاتین، بدون جداکننده و همراه کد سه‌حرفی ارز ثبت کنید.
5. Offer.url را با نشانی اصلی همان صفحه برابر کنید و هیچ مسیر خصوصی دریافت را در کد نیاورید.
6. تمام ویژگی‌های اختیاری را با یک پرسش بسنجید: آیا این داده واقعی، جاری و روی صفحه قابل مشاهده است؟
7. کد را ابتدا با Rich Results Test و Schema Markup Validator بررسی کنید. اولی الزامات قابلیت‌های گوگل و دومی انطباق عمومی با واژگان Schema.org را می‌سنجد.
8. پس از انتشار، URL زنده را با ابزار URL Inspection بررسی کنید تا نسخه رندرشده و دسترسی خزنده کنترل شود.
9. گزارش‌های Product snippets، Merchant listings و Unparsable structured data را در Search Console زیر نظر بگیرید و خطاهای قالبی را در همه نشانی‌های متاثر اصلاح کنید.
10. هر تغییر قیمت، توقف عرضه یا تغییر نام را هم‌زمان در صفحه، سبد خرید و JSON-LD منتشر کنید.

پیاده‌سازی خوب از کد طولانی شروع نمی‌شود؛ از یک صفحه محصول روشن و یک منبع داده واحد آغاز می‌شود. اگر اطلاعات قابل مشاهده، فرایند خرید و Product/Offer هم‌زمان به‌روزرسانی شوند، داده ساختاریافته توصیفی قابل اعتماد از پیشنهاد خواهد بود، بی‌آنکه خود محتوای دانلودی یا مسیر دسترسی آن افشا شود.

منابع و مطالعه بیشتر

• Merchant listing (Product, Offer) structured data — Google Search Central، 2026-07-07
• Product snippet (Product, Review, Offer) structured data — Google Search Central، 2025-12-10
• General Structured Data Guidelines — Google Search Central، 2026-07-10
• Product – Schema.org Type — Schema.org، بازبینی‌شده در 2026-08-15
• Offer – Schema.org Type — Schema.org، بازبینی‌شده در 2026-08-15
• Shopping reports and tools — Google Search Console Help، بازبینی‌شده در 2026-08-15