اسکیما برای فروشگاه و خدمات؛ Product، Local و Governance

Rich Results Test سبز است؛ اما قیمت اسکیما از Cache دیروز می‌آید، صفحه امروز «ناموجود» است، Review count افزونه با دیتابیس فرق دارد و دو Plugin هم‌زمان دو Product متفاوت منتشر می‌کنند. Syntax درست است، ولی Structured data حقیقت صفحه را غلط روایت می‌کند. این وضعیت از نداشتن اسکیما بدتر است، چون خطا در مقیاس Template تکثیر می‌شود.

Schema Markup ابزار توضیح Machine-readable محتوا و Entityهاست؛ نه دکمه افزایش رتبه، تضمین Rich result یا میان‌بُر اعتماد. پیاده‌سازی حرفه‌ای برای فروشگاه و سایت خدماتی از «کدام Type را اضافه کنیم؟» شروع نمی‌شود؛ از Source of truth، eligibility جاری هر Search feature، Entity graph، سازگاری با محتوای قابل‌مشاهده، تست در CI و Monitoring تولید شروع می‌شود.

Schema Markup چیست؟

Structured data قالب استانداردی برای توصیف نوع و ویژگی‌های موجودیت‌های صفحه است: این صفحه درباره چه Product، Organization، LocalBusiness، Article، Event یا Video است و رابطه آن‌ها چیست. Schema.org واژگان گسترده را تعریف می‌کند؛ موتور جست‌وجو تصمیم می‌گیرد کدام Type/Property را برای Feature خودش مصرف کند.

Google نیز صریح می‌گوید Structured data می‌تواند صفحه را برای Rich result واجد شرایط کند، اما نمایش را تضمین نمی‌کند. نتیجه به محتوا، Policy، Query، مکان، Device و تصمیم سیستم Search وابسته است. راهنمای عمومی داده ساختاریافته Google همچنین تطابق Markup با محتوای قابل‌مشاهده و پرهیز از اطلاعات گمراه‌کننده را لازم می‌داند.

سه لایه را از هم جدا کنید

Service یا HowTo می‌تواند Schema.org معتبر باشد، اما اعتبار Vocabulary به معنی Rich result فعال Google نیست. مستندات Google را برای رفتار Search نهایی بدانید؛ نه خروجی یک Generator یا فهرست Typeهای Schema.org. برای اصول JSON-LD و ساخت Graph پایه، راهنمای عمومی Schema Markup و Governance را ببینید؛ این مقاله روی فروشگاه و خدمات تمرکز دارد.

Schema چه کاری نمی‌کند؟

• رتبه، CTR، فروش یا حضور در Rich result را تضمین نمی‌کند.
• محتوای کم‌کیفیت، محصول ناموجود، آدرس جعلی یا Review ساختگی را معتبر نمی‌کند.
• جای Crawlability، Canonical، Indexability، Content یا Merchant/Business Profile را نمی‌گیرد.
• هر Property را به Feature قابل مشاهده Search تبدیل نمی‌کند.
• Graph دانش را صرفاً با افزودن sameAs یا چند Entity نمی‌سازد.
• خطای منبع Price/Stock/Hours/Policy را حل نمی‌کند؛ فقط آن را منتشر می‌کند.

Feature contract پیش از کدنویسی

Page type / intent: محصول، شعبه، خدمت، مقاله، ویدئو یا رویداد؟
Primary entity: موجودیت اصلی و canonical @id چیست؟
Consumer/feature: کدام Search feature و مستند جاری؟
Eligibility: page/content/required/recommended/policy constraints
Truth source: هر Property از کدام System و Owner؟
Freshness/SLA: Price/stock/hours/date/review چه‌قدر تازه؟
Render: server/initial HTML/JS/plugin/theme و duplicate risk
Validation: syntax/schema/feature/render/crawl/production
Measurement: eligible/valid/appearance/outcome و stop rule

اگر Feature هدف و Owner ندارید، «اضافه‌کردن هرچه Schema بیشتر» Backlog مفیدی نیست.

ماتریس جاری برای فروشگاه و خدمات

این ماتریس را Version و دوره‌ای بازبینی کنید. گالری رسمی Structured data مورد پشتیبانی Google مرجع Featureهای جاری است؛ Typeهای خارج از Gallery ممکن است برای Consumer دیگر یا فهم عمومی مفید باشند، اما وعده ظاهر خاص Google ندهید.

Entity graph پایدار بسازید

چند بلوک JSON-LD جدا می‌توانند یک Organization را با نام/Logo/URL متفاوت بسازند. از @id canonical و پایدار استفاده کنید و Entityها را به هم ارجاع دهید:

https://example.ir/#organization
https://example.ir/#website
https://example.ir/branches/tehran/#localbusiness
https://example.ir/product/sku-123/#product
https://example.ir/product/sku-123/#webpage
https://example.ir/product/sku-123/#breadcrumb

@id Identifier داخلی Graph است و لازم نیست صفحه جدا باز کند، اما URL پایدار و تحت کنترل انتخاب کنید. Product باید به Brand/Organization، WebPage به Product اصلی و Breadcrumb به مسیر همان Canonical وصل شود. Entityهای تکراری با IDهای اتفاقی Merge دشوار می‌شوند.

Schema پایه سایت

• Organization: نام رسمی، URL، Logo قابل Crawl، Contact/Policyهای واقعی و شناسه پایدار؛
• WebSite: نام و URL سایت؛ SearchAction را فقط اگر Search داخلی واقعی و Contract پشتیبانی‌شده دارید؛
• WebPage: URL/Name/primary entity و رابطه با Website؛
• BreadcrumbList: مسیر قابل‌مشاهده/منطقی صفحه، نه Breadcrumb ساختگی برای Keyword؛
• Article: برای محتوای تحریریه با Headline/Author/dateModified/image واقعی.

Sitewide Type را بدون توجه به Page purpose تزریق نکنید. صفحه Product باید Product را Main entity روشن داشته باشد؛ صفحه شعبه LocalBusiness خودش را؛ مقاله Article خودش را.

Product Schema: قرارداد با Catalog و Commerce

Product Markup از Copy دستی در SEO plugin نباید تغذیه شود. Name، SKU/GTIN/MPN، Brand، Image، Description، Variant، Price، Currency، Availability، Condition، Shipping، Return و Rating هرکدام System of record و Freshness متفاوت دارند.

مستند Merchant listing گوگل می‌گوید صفحات قابل خرید و متمرکز بر یک Product یا Variantهای آن برای این تجربه مناسب‌اند و داده Price/Availability سریع‌تغییر بهتر است در HTML اولیه باشد. همچنین Policy عمومی Shipping/Return می‌تواند در Organization قرار گیرد و Offer فقط Exception یا Reference را حمل کند.

نمونه JSON-LD محصول

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Product",
      "@id": "https://shop.example.ir/p/sku-123/#product",
      "name": "کالای نمونه مدل ۱۲۳",
      "image": ["https://shop.example.ir/media/sku-123.webp"],
      "description": "توضیحی که در صفحه نیز قابل مشاهده است.",
      "sku": "SKU-123",
      "brand": {"@type": "Brand", "name": "برند نمونه"},
      "offers": {
        "@type": "Offer",
        "url": "https://shop.example.ir/p/sku-123/",
        "price": "12500000",
        "priceCurrency": "IRR",
        "availability": "https://schema.org/InStock",
        "itemCondition": "https://schema.org/NewCondition",
        "seller": {"@id": "https://shop.example.ir/#organization"}
      }
    }
  ]
}

این عدد فقط وقتی درست است که صفحه همان قیمت را با واحد شفاف نشان دهد. IRR کد ریال است؛ «تومان» کد Currency استاندارد جایگزین نیست. اگر UI تومان نمایش می‌دهد، تبدیل/واحد را برای انسان شفاف و Feed/Markup/Checkout را بدون اختلاف عددی طراحی کنید. راه‌حل را روی داده و مستندات Consumer خود تست کنید.

Product variant را Entity واقعی بدانید

رنگ/سایز ممکن است Price، Stock، SKU/GTIN، Image و URL مستقل داشته باشد. Variant انتخاب‌شده در URL/HTML/Canonical/Offer باید یکی باشد. Markup یک Variant پیش‌فرض روی همه URLها، Stock/Price اشتباه می‌سازد.

• Parent group و Variant identity را در Catalog تعریف کنید.
• URL strategy و Canonical را با SEO/UX/Inventory هم‌سو کنید.
• هر Variant قابل ایندکس باید محتوای نماینده و Offer خودش داشته باشد.
• Unavailable/Discontinued/Preorder را با State صفحه و Status/redirect policy هماهنگ کنید.
• Structured data، Merchant feed و checkout را با SKU/URL Reconcile کنید.

راهنمای سئو فروشگاه، Catalog و Product مالک Strategy ایندکس/Variant/Facet است؛ Schema فقط Contract معنایی آن را منتشر می‌کند.

Review و AggregateRating: ستاره را نسازید

Review باید از کاربر واقعی، درباره Item درست، با Rating scale و Disclosure روشن باشد. میانگین و Count باید از همان Dataset قابل مشاهده محاسبه شوند. Review پنهان، انتخاب گزینشی فقط مثبت‌ها یا Rating تحریریه به‌جای کاربر خطر Policy دارد.

برای LocalBusiness/Organization، Google صفحات Entity که Review خودش را کنترل می‌کند برای Self-serving star feature واجد شرایط نمی‌داند—even اگر Widget شخص ثالث Embed شده باشد. مستند Review snippet گوگل این محدودیت را صریح بیان می‌کند. Product review قواعد متفاوت و خاص Product دارد؛ Type را برای دورزدن Policy عوض نکنید.

Shipping و Return را از Policy واحد بسازید

هزینه/زمان ارسال بر Destination، Order value، Weight، Carrier و Cutoff وابسته است. Return نیز Country، Category، Condition، Window، Method و Fee دارد. JSON-LD ثابت در Theme به‌سرعت کهنه می‌شود.

policy source → page-visible policy → checkout rules
              ↘ Organization/Product JSON-LD
               ↘ Merchant/feed config
                ↘ automated reconciliation + alert

Policy عمومی را یک Entity با @id پایدار بسازید و Product exception را جدا کنید. اگر Consumer/کشور هدف Property خاصی را پشتیبانی نمی‌کند، اطلاعات را همچنان برای کاربر واضح نگه دارید.

توضیح محصول و Schema باید یک Truth داشته باشند

Markup نباید Claimی را حمل کند که Copy صفحه، مدرک یا محصول تأیید نمی‌کند. Description را با Keyword stuffing، Emoji تبلیغاتی یا لیست Featureهای نامرتبط پر نکنید. راهنمای نوشتن توضیحات محصول برای Claim، Comparison و Measurement محتوای قابل‌مشاهده کاربرد دارد.

سایت خدماتی: Organization، LocalBusiness و Service

Organization هویت Provider را توضیح می‌دهد. LocalBusiness برای Location فیزیکی واقعی با Address، Phone، Hours و subtype دقیق است. Service نوع خدمت، Provider، AreaServed و Offer را در Graph عمومی بیان می‌کند؛ اما Service به‌تنهایی Feature نمایشی عمومی Google را تضمین نمی‌کند.

مستند رسمی LocalBusiness گوگل Address و Name را پایه eligibility می‌داند و برای Reservation/Order مستقیم به APIهای جدا اشاره می‌کند؛ افزودن Action دلخواه به JSON-LD دکمه Knowledge Panel را تضمین نمی‌کند. برای Strategy حضور محلی در ایران، راهنمای سئو محلی ایران را ببینید.

FAQPage و HowTo: وضعیت جاری را درست بفهمید

FAQ در صفحه برای کاربر، Conversion و پشتیبانی ارزش دارد؛ اما Google از ۲۰۲۳ Rich result FAQ را عمدتاً به سایت‌های شناخته‌شده و معتبر دولت/سلامت محدود کرد و HowTo rich results را کنار گذاشت. اعلام رسمی تغییر FAQ/HowTo می‌گوید Markup استفاده‌نشده مشکلی برای Search ایجاد نمی‌کند، ولی اثر قابل‌مشاهده هم ندارد.

بنابراین FAQPage را برای «گرفتن فضای بیشتر SERP» روی هر صفحه خدماتی Rollout نکنید. اگر Consumer دیگر یا Data architecture دلیل دارد، Markup باید همچنان با FAQ قابل‌مشاهده و Policy منطبق باشد. Answerها را کوتاه و ناقص نکنید تا فقط Schema ساخته شود.

VideoObject و Event

VideoObject را روی صفحه‌ای بگذارید که کاربر واقعاً Video را می‌بیند. Name، description، thumbnailUrl، uploadDate، duration و content/embed URL باید درست و Crawlable باشند. برای Video strategy و Transcript/Accessibility، راهنمای سئو محتوای غیرمتنی را ببینید.

Event باید رویداد واقعی با Leaf URL یکتا، Name، start/end، status، Location یا VirtualLocation، Organizer و Offer معتبر باشد. Sale کوتاه‌مدت یا «مشاوره رایگان» را Event ننامید. Feature/Region availability را در مستند Google و SERP هدف بررسی کنید.

JSON-LD چرا انتخاب رایج است؟

Google JSON-LD را در صورت امکان توصیه می‌کند، چون از HTML قابل‌مشاهده جدا و مدیریت Graph/Nesting ساده‌تر است؛ Microdata و RDFa نیز در شرایط مستند پشتیبانی می‌شوند. مقدمه رسمی Structured data گوگل تفاوت Format و توصیه نگهداری را توضیح می‌دهد.

جدا بودن از DOM به معنی جدا بودن از Truth نیست. Template باید هر دو را از یک View model بسازد؛ Copy دستی دو منبع ایجاد می‌کند.

روش پیاده‌سازی را با Ownership انتخاب کنید

برای Product سریع‌تغییر، Google Initial HTML را توصیه می‌کند تا Shopping crawl قابل‌اتکاتر باشد. یک Schema owner تعیین کنید و خروجی Theme/SEO plugin/review app/commerce app/tag manager را Inventory کنید؛ هر Tool حق تولید کدام Entity را دارد؟

Duplicate و Conflict را در Graph پیدا کنید

• دو Product با SKU یکسان و Price متفاوت؛
• Organization با Logo/Name/URLهای متفاوت و بدون @id مشترک؛
• Breadcrumb از Theme و Plugin با مسیرهای مختلف؛
• Article Author/Date از CMS و SEO plugin متناقض؛
• Review app با AggregateRating قدیمی کنار Product جدید؛
• Canonical صفحه A اما Offer URL/ID صفحه B؛
• Markup Staging یا example.com در Production.

Validator ممکن است هر بلوک را جدا معتبر بداند؛ Conflict بین Entityها نیاز Graph-level rule دارد.

امنیت JSON-LD

داده User/Partner را بدون Escape وارد <script> نکنید. رشته حاوی </script>، Quote، Unicode/Bidi و HTML می‌تواند Markup یا Security را بشکند. Serializer استاندارد، escaping مناسب HTML context، CSP، Allowlist field و Size limit استفاده کنید.

PII، Email/Phone خصوصی، Token، Internal ID حساس، Cost price یا Metadata عملیات را منتشر نکنید. JSON-LD برای هر بازدیدکننده قابل خواندن است.

Validation چهارمرحله‌ای

خطا باید Fix شود؛ Warning را بر Business value و امکان تأمین داده درست اولویت‌بندی کنید. اضافه‌کردن Property توصیه‌شده با داده حدسی کیفیت را بدتر می‌کند.

CI/CD برای Structured data

build representative pages
→ parse every application/ld+json block
→ assert allowed types and stable @id
→ validate required/recommended business rules
→ compare visible values vs graph
→ scan duplicate/conflicting entities
→ snapshot contract fixtures
→ deploy canary → crawl/render/reconcile → release

Fixtureها باید Product in-stock/out-of-stock/discount/variant، Location open/holiday، Article update، Video missing thumbnail و Event postponed/cancelled را پوشش دهند. چک‌لیست سئو داخلی صفحه برای Title/Canonical/Heading/Indexability کنار Schema اجرا شود.

Monitoring در Production

Eligible pages
→ markup emitted
→ syntax/feature valid
→ crawlable/indexable canonical
→ Google detected
→ search appearance observed
→ impression/click/qualified outcome

• Coverage هر Template/Type و درصد Missing/Duplicate/Invalid؛
• Price/stock/feed/offer mismatch age و count؛
• Search Console enhancement/merchant report و Manual actions؛
• Change point پس از Deploy/Plugin update/Template migration؛
• Search appearance impressions/clicks با Query/Page/Device/Country؛
• Qualified session/order/lead، نه CTR تنها.

مشاهده CTR بیشتر در صفحات دارای Rich result علت را اثبات نمی‌کند؛ آن صفحات ممکن است Brand، Rank یا Intent متفاوت داشته باشند. Cohort/Before-after با Season و Position کنترل‌شده یا rollout محدود بهتر است. Google نیز برای سنجش پیشنهاد می‌کند ابتدا روی بخشی از صفحات تست و داده Search Console را در زمان مقایسه کنید.

Migration و تغییر Template

هنگام Redesign/Replatform، Graph را مثل Data contract مهاجرت دهید:

1. Type/Property/@id/owner/source فعلی را Inventory و Crawl کنید.
2. Old/new rendered graph را per template Diff کنید.
3. Canonical/URL/@id و Entity relation را با URL map هماهنگ کنید.
4. Page/Feed/Business Profile/Checkout را Reconcile کنید.
5. Canary محدود، Rich Results/Inspection و Search Console را پایش کنید.
6. Duplicate legacy plugin/markup را پس از اثبات حذف کنید.
7. Rollback باید Template و Data source را باهم برگرداند.

راهنمای Redirect و مهاجرت URL برای Canonical/@id/URL move و راهنمای E‑E‑A‑T و Evidence برای Author/Review/Claim truth مفید است.

واقعیت ایران

• Currency: ریال/تومان را در UI، Feed، Markup و Checkout با Conversion شفاف و بدون تناقض نگه دارید؛ کد ساختگی نسازید.
• Availability: Stock، قیمت و Shipping تحت نوسان را با SLA/Cache invalidation و Alert به‌روز کنید.
• Location: آدرس فارسی/لاتین، تلفن با Country code، مختصات، ساعات عادی/تعطیل و شعبه را از Registry واحد بسازید.
• Date/time: نمایش شمسی برای کاربر می‌تواند با ISO ۸۶۰۱ و timezone درست در Markup همراه باشد؛ تبدیل را تست کنید.
• Eligibility: دسترسی/پشتیبانی Merchant/Profile/Feature/کشور هدف را از مستند رسمی و حساب واقعی در همان زمان بررسی کنید.
• RTL: Bidi و داده فارسی/لاتین را در Name/Address/Price/Identifier/URL و Serializer تست کنید.
• قانون: Review، قیمت، تخفیف، Return، داده و ادعای خدمات را با مقررات و متخصص مرتبط بررسی کنید.

Operating model و RACI

SEO نباید Price دستی را نگه دارد و Developer نباید معنای Return policy را حدس بزند. هر Property مهم Owner و Freshness SLO دارد.

نقشه ۳۰روزه

1. روز ۱ تا ۵: Page types، Graph موجود، Plugins، errors، Search features و Truth sources را Audit کنید.
2. روز ۶ تا ۱۰: Feature contract و Entity IDs، Owner/RACI، required/recommended policy را ثبت کنید.
3. روز ۱۱ تا ۱۵: یک Product template و یک Location/Service template را از Source واقعی بسازید.
4. روز ۱۶ تا ۲۰: Syntax/feature/render/truth/duplicate تست و CI fixtures را تکمیل کنید.
5. روز ۲۱ تا ۲۵: Canary محدود، Crawl/Inspection/Search Console و Reconciliation را پایش کنید.
6. روز ۲۶ تا ۳۰: Evidence/Outcome/Cost را مرور و درباره Scale/Hold/Remove تصمیم بگیرید.

اشتباه‌های رایج

• اسکیما به‌عنوان فاکتور رتبه یا تضمین Rich result/CTR؛
• پیاده‌سازی هر Type موجود در Schema.org بدون Feature contract؛
• FAQ/HowTo برای فضای بیشتر SERP در سایت خدماتی عادی؛
• Service یا Action با وعده دکمه/Feature خاص Google؛
• Price/stock/hours/review دستی و کهنه؛
• Review خودخدمت برای ستاره LocalBusiness/Organization؛
• Product یکسان روی Category یا Variantهای متفاوت؛
• چند Plugin/Theme/Tag با Entityهای متناقض؛
• اعتماد به Test سبز بدون Render/Crawl/Truth reconciliation؛
• تزریق Client-side Price سریع‌تغییر بدون Reliability؛
• PII/داده داخلی یا رشته User بدون Escape در JSON-LD؛
• سنجش با CTR خام و نداشتن Rollback/Governance.

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

• Page intent، Primary entity، Consumer/Feature و مستند جاری ثبت شده‌اند.
• Vocabulary validity از Google eligibility/appearance جدا شده است.
• هر Property با محتوای قابل‌مشاهده، Source و Freshness SLO منطبق است.
• Organization/Product/Location/Service/Page/Breadcrumb @id پایدار دارند.
• Product/Variant/Offer/Price/Currency/Stock/URL/Feed/Checkout Reconcile می‌شوند.
• Review واقعی، قابل مشاهده، کامل و منطبق با Policy Type است.
• Shipping/Return/Hours/Event status از Policy/Operation واحد می‌آیند.
• Plugin/Theme/app/tag outputs Inventory و Duplicate/Conflict حذف شده‌اند.
• Serializer امن، Escape/Size/PII/secret controls دارد.
• Schema Validator، Rich Results Test، URL Inspection و Production truth هر چهار اجرا می‌شوند.
• CI Fixtureها حالت‌های stock/discount/variant/holiday/postponed/error را پوشش می‌دهند.
• Coverage→detected→appearance→qualified outcome و drift پایش می‌شود.
• Migration/Canary/Rollback، Entity/URL/Data را یکپارچه می‌بیند.
• Currency/date/RTL/location/eligibility/قانون ایران بررسی شده‌اند.
• Scale/Hold/Remove با Evidence و هزینه عملیات تصمیم‌گیری می‌شود.

جمع‌بندی: Schema Markup خوب «کد بیشتر» نیست؛ Truth قابل نگهداری و قابل آزمون است. ابتدا Feature و Eligibility جاری را مشخص کنید، Entity graph پایدار بسازید، Propertyها را از Catalog/Policy/Location/Content واقعی تغذیه کنید و Pipeline را از Syntax تا Outcome پایش کنید. Rich result یک امکان است، نه وعده؛ صحت داده و تجربه کاربر باید حتی وقتی Feature نمایش داده نمی‌شود ارزشمند بماند.

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

آیا Schema Markup باعث افزایش رتبه می‌شود؟

تضمینی یا فاکتور مستقیمی که با افزودن کد رتبه را بالا ببرد نیست. Structured data به فهم محتوا و eligibility برخی Rich resultها کمک می‌کند؛ نمایش Feature و اثر CTR/Outcome وابسته به Query، Position، Page، Policy و تصمیم Google است و باید اندازه‌گیری شود.

برای فروشگاه Product Schema کافی است؟

خیر. Product/Offer باید با Catalog، Variant، Price، Currency، Stock، Shipping/Return، Review، Landing page، Feed و Checkout منطبق باشد. همچنین Crawlability، Canonical، Content و Merchant eligibility جداگانه لازم‌اند.

آیا FAQ Schema هنوز در Google نمایش داده می‌شود؟

Rich result FAQ عمدتاً به سایت‌های شناخته‌شده و معتبر دولت/سلامت محدود شده است. FAQ برای کاربر همچنان مفید است و Markup ممکن است برای Consumer دیگر ارزش داشته باشد، اما سایت خدماتی عادی نباید نمایش FAQ در Google را انتظار یا وعده کند.

Rich Results Test سبز است؛ چرا نتیجه غنی نمی‌بینم؟

سبز بودن یعنی خطاهای eligibility قابل تشخیص ابزار رفع شده‌اند، نه تضمین نمایش. Crawl/index/canonical، محتوای قابل مشاهده، Policy، Quality، Query/Device/Location و تصمیم الگوریتم اثر دارند. URL Inspection و Search Console/SERP را نیز بررسی کنید.

افزونه Schema بهتر است یا پیاده‌سازی اختصاصی؟

به Page types، Truth sources، Variant/Policy، کنترل Template و ظرفیت تیم بستگی دارد. افزونه برای نیاز ساده سریع است؛ پیاده‌سازی Data-driven برای Graph پیچیده کنترل بیشتری می‌دهد. در هر روش یک Owner، تست Duplicate/Truth، CI و Rollback لازم است.