اسکیما مارکاپ و داده‌های ساختاریافته؛ راهنمای JSON-LD و Rich Results

اگر کد Schema شما در ابزار تست سبز است، فقط ثابت کرده‌اید بخشی از Syntax یا Eligibility فنی درست است؛ نه اینکه Google حتماً ستاره، قیمت یا نتیجه غنی نشان می‌دهد، CTR بالا می‌رود یا رتبه بهتر می‌شود. داده ساختاریافته باید بازتاب دقیق، تازه و قابل‌مشاهده محتوای صفحه باشد و در Production با قیمت، موجودی، نویسنده، تاریخ، URL و Policy همگام بماند. ارزش اصلی آن از همین قرارداد داده می‌آید، نه از تعداد Typeهایی که به صفحه اضافه کرده‌اید.

در این راهنما «میکرودیتا» را با کل Schema markup یکی نمی‌گیریم. Vocabulary، Syntax و Feature را جدا می‌کنیم؛ نوع مناسب را از هدف صفحه انتخاب، JSON-LD را از Source of truth تولید، Duplicateهای Theme/Plugin را مهار، با دو Validator متفاوت تست و Coverage/Freshness را در مقیاس پایش می‌کنیم. برای فروشگاه و رویداد ایرانی نیز تومان/ریال، تاریخ جلالی/ISO، موجودی و بازار قابل‌پشتیبانی را دقیق مدیریت می‌کنیم.

Snapshot: قابلیت‌ها و اسناد Google در ۱۸ مرداد ۱۴۰۵ (۹ اوت ۲۰۲۶) بازبینی شده‌اند. Search appearanceها، Propertyهای لازم و Availability کشور/زبان تغییر می‌کنند؛ مستند همان Feature را در روز اجرا دوباره بخوانید.

چهار مفهوم که معمولاً با هم اشتباه می‌شوند

Schema.org دایره‌ای بزرگ‌تر از Featureهای Google دارد. Property ممکن است در Vocabulary معتبر باشد اما برای یک Rich result گوگل استفاده نشود. برعکس، سبزشدن در Schema.org Validator به معنی پاس‌شدن Requirementهای Google نیست. مقدمه رسمی Structured Data گوگل نیز می‌گوید برای رفتار Google باید مستند Search Central همان Feature را مرجع قطعی بگیرید.

میکرودیتا، JSON-LD و RDFa چه تفاوتی دارند؟

میکرودیتا مجموعه Attributeهایی است که داخل HTML دیده‌شدنی می‌نشیند؛ RDFa نیز Linked data را با Attributeها بیان می‌کند؛ JSON-LD یک Block مستقل JSON در <script type="application/ld+json"> است. Google هر سه را پشتیبانی می‌کند و JSON-LD را در اغلب موارد به‌دلیل نگهداری آسان‌تر پیشنهاد می‌دهد.

«JSON-LD بهتر است» به معنی چسباندن یک JSON ثابت به همه صفحات نیست. بهترین فرمت، فرمت قابل نگهداری در معماری شماست. یک JSON-LD دقیق و Template-driven معمولاً انتخاب خوبی است؛ Microdata سالم نیز از JSON-LD نادرست بهتر است.

Schema چه اثری بر سئو دارد و چه چیزی را تضمین نمی‌کند؟

Structured data به موتور جست‌وجو سرنخ صریح درباره Entity و Content می‌دهد و می‌تواند صفحه را برای بعضی Search appearanceها واجد شرایط کند. اما Eligibility با نمایش فرق دارد. راهنمای عمومی داده ساختاریافته Google صریح است: حتی Markup صحیح در Rich Results Test نیز نمایش نتیجه غنی را تضمین نمی‌کند.

• رتبه: یک Property بیشتر، جایگاه مشخص نمی‌خرد. Structured-data manual action می‌تواند Eligibility نتیجه غنی را حذف کند؛ طبق راهنمای Google لزوماً Rank نتیجه وب را تغییر نمی‌دهد.
• CTR: Search appearance متفاوت ممکن است CTR را تغییر دهد، اما Query، Rank، Device، Brand و Season هم اثر دارند. افزایش عمومی و قطعی وجود ندارد.
• Traffic: نمایش قیمت/موجودی گاهی کلیک نامرتبط را کم می‌کند؛ Traffic کمتر با Conversion بهتر می‌تواند نتیجه مطلوب‌تری باشد.
• AI/Voice: Schema یک قرارداد داده مفید است، اما راه اختصاصی یا تضمینی برای Citation در پاسخ‌های AI یا Voice assistant نیست.
• درک محتوا: Markup نمی‌تواند متن ضعیف، Entity مبهم یا اطلاعات متناقض سایت را جبران کند.

از Search feature شروع کنید، نه از فهرست Schema.org

ابتدا Outcome و Page type را مشخص کنید و سپس گالری جاری Structured Data پشتیبانی‌شده Google را ببینید. Typeای که Feature یا مصرف داخلی معتبر ندارد، فقط هزینه تولید و Freshness می‌سازد.

این جدول مجوز افزودن همه گره‌ها نیست. Main entity باید هدف اصلی صفحه را نشان دهد. اگر صفحه Recipe همراه Video دارد، گره‌ها را با Nesting یا @id مرتبط کنید؛ چند Block متناقض بدون Relation یک Entity graph قابل‌اعتماد نمی‌سازد.

FAQ و HowTo: توصیه قدیمی را به‌روزرسانی کنید

FAQ در محتوا همچنان برای کاربر مفید است، اما FAQPage را برای اشغال بیشتر SERP نسخه عمومی نکنید. طبق اعلام رسمی تغییر FAQ و HowTo، FAQ rich result فقط برای سایت‌های شناخته‌شده و معتبر دولتی و سلامت به‌طور منظم نمایش داده می‌شود؛ HowTo rich result نیز بعداً از Search، Report و Rich Results Test حذف شد. Markup بلااستفاده الزاماً مشکل نمی‌سازد، اما اثر بصری وعده‌داده‌شده ندارد و Maintenance debt می‌سازد.

QAPage نیز با FAQPage یکی نیست: QAPage برای یک سؤال و پاسخ‌های کاربران است؛ FAQ مجموعه پرسش/پاسخ خود سایت است. Review، Forum و Profile هم Policy و Page shape مخصوص دارند. نوع نزدیک ولی اشتباه انتخاب نکنید.

Entity graph: Typeها را به یکدیگر وصل کنید

به‌جای تکرار Organization با نام‌ها و Logoهای مختلف در هر Plugin، یک شناسه پایدار بسازید؛ معمولاً URL Canonical با Fragment مانند https://example.com/#organization. Article، WebSite، Author و Breadcrumb می‌توانند به Entityهای مشترک ارجاع دهند.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "نمونه",
      "url": "https://example.com/",
      "logo": {
        "@type": "ImageObject",
        "url": "https://example.com/media/logo.png"
      }
    },
    {
      "@type": "Person",
      "@id": "https://example.com/authors/sara/#person",
      "name": "سارا احمدی",
      "url": "https://example.com/authors/sara/"
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/blog/schema-guide/#article",
      "url": "https://example.com/blog/schema-guide/",
      "headline": "راهنمای اسکیما مارکاپ",
      "inLanguage": "fa-IR",
      "datePublished": "2026-08-09T09:00:00+03:30",
      "dateModified": "2026-08-09T10:30:00+03:30",
      "author": {"@id": "https://example.com/authors/sara/#person"},
      "publisher": {"@id": "https://example.com/#organization"},
      "mainEntityOfPage": "https://example.com/blog/schema-guide/"
    }
  ]
}
</script>

این مثال آموزشی است و همه Propertyهای مناسب پروژه شما را ندارد. URL، تاریخ، نویسنده و تصویر باید واقعاً وجود و با صفحه تطابق داشته باشند. مستند جاری Article structured data را برای Propertyها و Author best practices بررسی کنید.

Source of truth: Schema را از همان داده صفحه تولید کنید

بزرگ‌ترین خطای Production معمولاً Syntax نیست؛ Drift است. قیمت روی صفحه از Commerce API می‌آید و JSON-LD از Field دستی قدیمی. تاریخ Visible جلالی تغییر می‌کند اما ISO markup ثابت می‌ماند. Author در CMS عوض می‌شود ولی SEO plugin نام Admin را می‌فرستد.

Pipeline مطلوب:

1. Domain data: Product، Offer، Author، Event و Organization در Source معتبر تعریف می‌شوند.
2. Page model: همان داده برای UI، API و Schema mapping مصرف می‌شود.
3. Mapping contract: هر Property منبع، Transformation، Null policy و Owner دارد.
4. Render: HTML قابل‌مشاهده و JSON-LD از Snapshot واحد تولید می‌شوند.
5. Validation: Syntax، Feature eligibility، Consistency و Freshness تست می‌شوند.
6. Observation: Coverage، Error، Search appearance و Drift در Production پایش می‌شوند.

WordPress: Theme، افزونه و WooCommerce را هم‌زمان Emit نکنید

Yoast، Rank Math، WooCommerce، Theme و افزونه Schema می‌توانند هرکدام Organization، Article، Breadcrumb یا Product بسازند. چند Graph همیشه خطا نیست، اما Duplicate و تناقض می‌تواند Entity را مبهم کند. پیش از افزودن Plugin جدید، HTML عمومی چند Template را Extract کنید.

تنظیم را ابتدا در Staging انجام دهید، اما Validation نهایی روی Public render لازم است. Cache، Minifier، Consent manager، CDN و Plugin conflict ممکن است فقط در Production خروجی را تغییر دهند.

GTM برای Schema حیاتی Source of truth مناسبی نیست

Google می‌تواند JSON-LD Injectشده با JavaScript را بخواند، اما این توانایی دلیل خوبی برای تولید Core schema در Tag manager نیست. GTM به Consent، Blocker، Timing، Container permission و JavaScript failure وابسته است و معمولاً به Domain data کامل دسترسی ندارد. برای آزمایش محدود ممکن است کاربرد داشته باشد؛ برای Product price، Availability، Job status یا Article identity، Render در Template/Application نزدیک Source of truth پایدارتر است.

اگر مجبور به Client-side generation هستید، Rendered HTML را با URL Inspection، Failure حالت Consent/JS و Monitoring واقعی بررسی کنید. Schema نباید فقط در Preview mode وجود داشته باشد.

Product و Offer: قیمت، موجودی و Variant را قرارداد داده بدانید

مستند Product structured data میان Product snippet و Merchant listing فرق می‌گذارد. صفحه نقدی که خرید مستقیم ندارد و صفحه Merchant که کاربر می‌تواند خرید کند، Requirement یکسان ندارند. Product feed در Merchant Center و Page markup نیز می‌توانند مکمل باشند و باید همگام بمانند.

فیلدهای پرریسک

• price: عدد فعال همان Offer، بدون Symbol و Separator؛ قیمت «از» یا Range را طبق Feature و Property مجاز مدل کنید، نه حدس.
• priceCurrency: کد سه‌حرفی ISO ۴۲۱۷.
• availability: وضعیت واقعی SKU/Offer، نه موجودی Parent فرضی.
• url: مقصد خرید یا Product canonical واقعی و قابل Crawl.
• sku/gtin/mpn: فقط شناسه واقعی؛ شناسه اختراعی برای پُرکردن فیلد نسازید.
• review/aggregateRating: از Review واقعی و قابل‌مشاهده بر اساس Policy؛ Rating ساختگی یا ناقص ممنوع.
• shipping/return: Policy دقیق همان بازار/Offer؛ متن حقوقی را با JSON متناقض نکنید.

تومان و ریال در JSON-LD

کدهای IRT یا TOMAN ISO ۴۲۱۷ نیستند. IRR ریال ایران است. اگر UI قیمت را تومان نمایش می‌دهد، باید نمایش و Markup بدون ابهام به یک مبلغ واحد اشاره کنند: مثلاً ۲٬۵۰۰٬۰۰۰ تومان = ۲۵٬۰۰۰٬۰۰۰ ریال. در JSON عدد را با رقم ASCII و priceCurrency: "IRR" بنویسید و معادل ریالی/قاعده تبدیل را در صفحه به‌روشنی ارائه کنید. از ضرب اشتباه ده‌برابری و Cache قیمت قدیمی جلوگیری کنید.

این کار تضمین Availability تجربه Merchant در ایران نیست؛ Country/Language/Program eligibility و الزامات Merchant Center را جدا بررسی کنید. داده صحیح را برای گرفتن Feature غیرقابل‌دسترس جعل نکنید.

Article و Author: نام نویسنده را به Entity واقعی وصل کنید

Headline، Image، datePublished، dateModified، Author و Publisher باید با Page و History واقعی همسو باشند. «به‌روزرسانی» را فقط وقتی dateModified کنید که تغییر معنادار و قابل‌اعتماد رخ داده باشد. چند نویسنده را Array از Person/Organizationهای جدا بفرستید؛ نام‌ها را در یک String ترکیب نکنید.

Author profile باید درباره هویت و صلاحیت مرتبط Evidence بدهد؛ Schema جای Bio یا Editorial policy را نمی‌گیرد. راهنمای E‑E‑A‑T و شواهد نویسنده/بازبین کمک می‌کند Markup از واقعیت تحریریه پشتیبانی کند.

Organization و LocalBusiness: موجودیت قانونی را دقیق توصیف کنید

Organization را معمولاً در Home/About و Graph site-wide به‌صورت پایدار تعریف کنید؛ هر صفحه را با ده‌ها ContactPoint متناقض پُر نکنید. مستند جاری Organization Propertyهایی برای نام، URL، Logo، تماس، Address، شناسه‌ها و در OnlineStore حتی Shipping/Return policy دارد؛ فقط موارد واقعی و Applicable را اضافه کنید.

• نام تجاری، نام حقوقی و Alternate name را قاطی نکنید.
• sameAs را برای Profile رسمی Entity بگذارید، نه هر Directory یا Review page.
• شماره تماس با Country code و مقصد واقعی Support هماهنگ باشد.
• Address خصوصی یا غیرقابل‌مراجعه را صرفاً برای Rich result منتشر نکنید.
• LocalBusiness را فقط برای Business/Location واقعی و مناسب به کار ببرید؛ Service area را جعل نکنید.

Review و Rating: ستاره را نسازید؛ Evidence را مدل کنید

Review باید درباره Item مشخص، اصیل، قابل مشاهده و مطابق Policy همان Feature باشد. AggregateRating باید از مجموعه Reviewهای نمایش‌داده‌شده و معتبر مشتق شود و Count/Value با Data source هماهنگ باشد. Google از ۲۰۱۹ Self-serving review snippet را برای Organization و LocalBusinessهایی که Review را درباره خودشان روی سایت خود کنترل می‌کنند نمایش نمی‌دهد؛ اعلام رسمی Review rich results را ببینید.

این محدودیت به معنی حذف Review مشتری از UX نیست؛ فقط وعده ستاره SERP را کنار می‌گذارد. Review policy، Verified purchase، Incentive disclosure، Moderation، Appeal و Fraud detection را بخشی از Trust system بدانید. چارچوب اعتماد و Social proof قابل‌راستی‌آزمایی این لایه را عمیق‌تر می‌کند.

Event: تقویم جلالی را به ISO دقیق نگاشت کنید

در راهنمای Event گوگل هر Event یا اجرای بلیت‌دار باید URL مستقل و داده تاریخ/مکان دقیق داشته باشد. startDate و endDate را ISO ۸۶۰۱ بنویسید؛ تاریخ Visible می‌تواند جلالی باشد اما Markup باید همان لحظه را به میلادی و Offset درست نمایش دهد.

• اگر ساعت معلوم نیست، Midnight ساختگی ننویسید؛ Date بدون زمان استفاده کنید.
• برای رویداد لغو/تعویق/جابجاشده، Status و previousStartDate را طبق Doc به‌روز کنید؛ Page را فوراً حذف نکنید.
• Online، Offline یا Mixed location را درست مدل و URL ورود را با Privacy مدیریت کنید.
• Offer price/currency/availability و Ticket URL باید زنده و هماهنگ باشند.
• Availability منطقه/زبان Google Event experience محدود است؛ Valid بودن Schema تضمین نمایش در ایران نیست.

تصویر و ویدئو در Schema نیز باید قابل Crawl باشند

Logo، Article image، Product image و Video thumbnail باید مرتبط، پایدار، Crawlable و Indexable باشند. URL موقت Signed، Hotlink Block، robots منع‌کننده یا تصویر Loginشده Feature را می‌شکند. برای Watch page، Thumbnail، VideoObject و Player از راهنمای تصویر و ویدئو در سایت استفاده کنید.

پنج لایه Validation؛ یک ابزار کافی نیست

Error و Warning را Contextual بخوانید. Missing required property Eligibility را می‌شکند؛ Recommended property ممکن است کیفیت را بالا ببرد، اما افزودن مقدار حدسی بدتر است. «Valid» به معنی Accurate و Fresh نیست؛ Validator از Backend موجودی یا حق واقعی Review خبر ندارد.

Release process: از نمونه کوچک تا Rollout

1. Registry: Template → Main type → Consumer/Feature → Owner → Source → SLA.
2. Contract: Required/Recommended، Transform، Null، Locale، ID و Freshness.
3. Fixture: نمونه Normal، Missing، Edge، RTL، Quote/HTML و Out-of-stock.
4. Unit/schema test: JSON parse، Type/shape و Escape.
5. Integration test: Visible DOM ↔ JSON-LD ↔ Source data.
6. Staging validation: Schema validator و Rich Results Test روی نمونه‌ها.
7. Canary: چند URL نماینده، URL Inspection و Crawl عمومی.
8. Rollout: Segment کنترل‌شده با Dashboard Error/Coverage/Freshness.
9. Post-release: Search Console، Manual actions، Search appearance و Incident.
10. Change management: Doc update، Plugin/Template release و Deprecation trigger.

برای ممیزی هم‌زمان Crawl/Index/Canonical/Sitemap و Structured data از چک‌لیست کامل SEO Audit استفاده کنید؛ Schema سالم روی صفحه noindex یا Canonical اشتباه Outcome نمی‌سازد.

Governance در مقیاس

Schema registry

Coverage و Freshness dashboard

«۹۸٪ URLها Schema دارند» Metric کافی نیست. این شاخص‌ها را کنار هم ببینید:

• Eligible template coverage و دلیل URLهای مستثنا
• Parse success، Error/Warning بر Type و Release
• Duplicate/conflicting node و Orphan @id
• Visible↔Markup consistency برای Price، Stock، Date، Author و Rating
• Image/URL crawlability و Status
• Freshness lag و Cache age
• Search Console valid/invalid item trend و Manual action
• Impression/Click/CTR Search appearance با Rank/Query/Device guardrail

امنیت و حریم خصوصی JSON-LD

JSON-LD Public است؛ چیزی را که کاربر نباید ببیند در آن نگذارید. Email شخصی، تلفن داخلی، شناسه ملی/مالیاتی حساس، Draft، Supplier cost، Inventory داخلی، Token، API URL خصوصی یا داده مشتری نباید به‌خاطر «ماشین‌خوان شدن» نشت کند.

JSON را با Serializer تولید کنید، نه String concatenation. Title یا Description حاوی Quote، </script> یا محتوای کاربر می‌تواند Markup را بشکند یا سطح XSS بسازد. Escape مناسب Context HTML Script، محدودکردن Fieldها و Security test لازم است. GTM/Plugin خارجی را نیز Supply-chain code بدانید.

Ethics و Policy: Markup نباید واقعیت را آرایش کند

• قیمت تخفیفی بدون قیمت فعال واقعی یا پایان ساختگی نگذارید.
• Availability را InStock نکنید چون «به‌زودی می‌رسد».
• Review تحریریه را به‌عنوان Aggregate customer rating مخلوط نکنید.
• Author یا Credential صوری برای E‑E‑A‑T نسازید.
• Service را Product و Promotion را Event نام‌گذاری نکنید فقط چون Preview جذاب‌تر است.
• Content پنهان یا نامرتبط را Markup نکنید.

راهنمای طراحی اخلاقی و پرهیز از Dark pattern را به SERP promise نیز تعمیم دهید: چیزی که قبل از Click وعده می‌دهید باید پس از Click حاضر باشد.

شرایط ایران: زبان، تاریخ، ارز و هویت

برای صفحه محصول، قیمت Schema باید با UI، سبد، Checkout و Backend آشتی داده شود. راهنمای UX فروشگاه و Reconciliation Journey کمک می‌کند Rich result با واقعیت خرید ناسازگار نشود.

سنجش اثر: Attribution را با علیت اشتباه نگیرید

Google پیشنهاد می‌کند چند صفحه پایدار را قبل/بعد بررسی کنید، اما Season، Rank و Query mix می‌توانند نتیجه را جابه‌جا کنند. برای شواهد بهتر:

1. URLهای Eligible مشابه را بر Template/Intent/Rank/Traffic Match کنید.
2. Rollout مرحله‌ای یا Holdout قابل‌دفاع بسازید.
3. Index/eligibility lag را در Window لحاظ کنید.
4. Search appearance impression/click/CTR را با Position، Query، Device و Country Segment کنید.
5. Landing quality و Conversion/Revenue/Qualified lead را Guardrail بگیرید.
6. تغییر Title، Price، Content یا Internal link را هم‌زمان با Test انجام ندهید.

CTR بالاتر با Traffic نامرتبط یا Price قدیمی موفقیت نیست. Data contract و Warehouse را با راهنمای تحلیل داده بازاریابی به Search Console و Outcome کسب‌وکار وصل کنید.

برنامه ۳۰روزه پیاده‌سازی Schema

1. هفته اول — Inventory: Templateها، Emitterها، Graph فعلی، Feature جاری، Error و Sourceها را Map کنید؛ Duplicate را پیدا کنید.
2. هفته دوم — Contract: دو Template با ارزش بالا انتخاب، Main entity/@id/Source/Null/Freshness/Owner و Fixtures را تعریف کنید.
3. هفته سوم — Build/validate: JSON-LD را از داده مشترک UI تولید، Unit/consistency/security test و دو Validator را اجرا کنید.
4. هفته چهارم — Canary/monitor: روی نمونه عمومی منتشر، URL Inspection/Crawl/Search Console را کنترل و سپس مرحله‌ای Scale کنید.

چک‌های Schema را در فرایند سئو داخلی قبل و بعد از انتشار قرار دهید تا تغییر Content/Canonical/Media دوباره آن را نشکند.

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

• Vocabulary، Syntax و Google feature از هم تفکیک شده‌اند.
• Feature در Gallery جاری وجود و برای Country/Language/Page type معنا دارد.
• Main entity هدف واقعی صفحه را نشان می‌دهد و گره‌ها با @id پایدار مرتبط‌اند.
• یک Emitter اصلی مشخص و خروجی Theme/Plugin/GTM متناقض حذف شده است.
• UI و JSON-LD از Source مشترک تولید می‌شوند.
• محتوای Markup قابل مشاهده، اصیل، مرتبط، تازه و غیرگمراه‌کننده است.
• Requiredها کامل و Recommendedها فقط با مقدار واقعی افزوده شده‌اند.
• Product price/currency/stock/variant و Review count با Backend آشتی دارند.
• Author/Publisher/Date/Image/URL واقعی و Crawlable هستند.
• FAQ/HowTo بر وعده منقضی Rich result تکیه ندارند.
• JSON parse، Schema.org graph و Google eligibility جدا تست شده‌اند.
• Public rendered HTML، URL Inspection و Search Console بررسی شده‌اند.
• PII/Secret/Internal data حذف و JSON با Serializer/Escape امن تولید شده است.
• تومان/ریال، ISO date، Offset، فارسی و Availability ایران درست‌اند.
• Coverage، Duplicate، Freshness، Manual action و Search appearance Owner دارند.
• Rollout مرحله‌ای، Change log، Alert و Trigger بازبینی مستندات برقرار است.

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

• نامیدن کل Structured data به «میکرودیتا» و مخلوط‌کردن Format با Vocabulary.
• افزودن همه Typeهای Schema.org به امید رتبه یا AI citation.
• وعده افزایش قطعی CTR، Traffic یا Rank چون Rich Results Test سبز است.
• استفاده از FAQPage یا HowTo بر پایه Screenshotهای قدیمی SERP.
• Duplicate Organization/Article/Product از چند افزونه.
• قیمت/موجودی/Rating دستی و جدا از Source واقعی.
• تزریق Core schema با GTM بدون Render/Consent/Failure test.
• اعتبارسنجی فقط در Schema.org یا فقط در Rich Results Test.
• IRR را تومان گرفتن یا نوشتن IRT/TOMAN به‌عنوان Currency استاندارد.
• انتشار Review، Author، Event یا Offer نامرئی/ساختگی برای گرفتن Feature.

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

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

Markup به Google سرنخ ساختاری و Eligibility بعضی Search appearanceها می‌دهد، اما جایگاه مشخص یا Rich result را تضمین نمی‌کند. اثر را با Impression/CTR/Outcome و Guardrail Rank/Query/Device بسنجید؛ از ادعای «فاکتور غیرمستقیم چون CTR سیگنال است» نتیجه قطعی نسازید.

JSON-LD بهتر است یا Microdata؟

Google هر سه فرمت JSON-LD، Microdata و RDFa را می‌پذیرد و JSON-LD را معمولاً به‌خاطر نگهداری ساده‌تر پیشنهاد می‌کند. فرمت سالم و همگام با Page مهم‌تر از نام فرمت است. JSON-LD ثابت و قدیمی از Microdata درست بدتر است.

چرا Schema معتبر است اما Rich result نمایش داده نمی‌شود؟

Valid بودن فقط بخشی از Eligibility است. Feature ممکن است برای نوع صفحه/کشور/زبان محدود، محتوای Markup نامرئی یا کم‌کیفیت، Page/Crawl/Index مشکل‌دار یا Algorithm نمایش دیگری را مناسب‌تر بداند. Google نمایش را حتی پس از پاس Rich Results Test تضمین نمی‌کند.

آیا FAQ Schema هنوز مفید است؟

FAQ محتوا برای کاربر مفید است؛ اما FAQ rich result طبق سیاست جاری به سایت‌های شناخته‌شده و معتبر دولت و سلامت محدود است و برای اغلب سایت‌ها منظم نمایش داده نمی‌شود. اگر مصرف دیگری ندارید، Markup آن ممکن است فقط Maintenance debt باشد.

برای تست Schema از چه ابزاری استفاده کنیم؟

JSON parser برای Syntax، Schema Markup Validator برای Graph/Vocabulary، Rich Results Test برای Feature گوگل، URL Inspection/Crawl برای Render عمومی و Search Console برای Fleet health. هیچ‌کدام به‌تنهایی Accuracy قیمت، موجودی، Author یا Review را ثابت نمی‌کند؛ Reconciliation با Source لازم است.

جمع‌بندی

اسکیما مارکاپ پروژه «افزودن چند خط JSON» نیست؛ قرارداد داده میان محتوای قابل‌مشاهده، Source داخلی و مصرف‌کننده‌های بیرونی است. Main entity و Feature جاری را آگاهانه انتخاب کنید، JSON-LD را از همان داده UI بسازید، Entityها را با شناسه پایدار وصل کنید، Pluginهای متناقض را مهار کنید و Validation فنی را از Accuracy و نمایش واقعی جدا بدانید. وقتی Registry، Freshness، Rollout و Monitoring دارید، Structured data از ترفند سئو به زیرساخت قابل‌اعتماد تبدیل می‌شود.