راهنمای جامع اعتبارسنجی (Validate) و دیباگ کردن اسکیمای سفارشی [راهنمای گام به گام]

سلام! سارا بحرانی هستم از تیم «وزیر سئو». اگه تو هم تا امروز فقط از اسکیمای استاندارد مثل Article یا Product استفاده کردی، کارت درسته، اما بذار بگم که فقط در سطح اول موندی! دنیای واقعی سئوی پیشرفته، جایی شروع می‌شه که تو بتونی «تخصص» منحصر به فرد کسب‌وکارت رو به زبان خود گوگل بهش بفهمونی. اینجا دقیقاً جاییه که «اسکیمای سفارشی» (Custom Schema) وارد بازی می‌شه.

اسکیمای سفارشی، سطح نهایی و پیشرفته‌ی پیاده سازی داده های ساختاریافته است. این ابزار به تو اجازه می‌ده که فراتر از قالب‌های آماده بری و مستقیماً به «گراف دانش» (Knowledge Graph) گوگل اطلاعات تزریق کنی. اما پیاده‌سازی اون پر از تله‌های فنیه.

تو این راهنمای جامع، من می‌خوام بهت قدم به قدم یاد بدم که چطور اسکیمای سفارشی خودت رو بنویسی، چطور اون رو «اعتبارسنجی» (Validate) کنی تا از نظر فنی بی‌نقص باشه، و چطور «دیباگ» (Debug) کنی تا مطمئن بشی گوگل دقیقاً همون برداشتی رو داره که تو می‌خوای. آماده‌ای که تخصص (E-A-T) سایتت رو به سطح دیگه‌ای ببری؟

جدول کاربردی: تفاوت کلیدی اعتبارسنجی و دیباگ کردن اسکیما

ویژگی مقایسه	✅ اعتبارسنجی (Validation)	🔍 دیباگ کردن (Debugging)
هدف اصلی	بررسی «صحت گرامری» (Syntax) کد	بررسی «پشتیبانی گوگل» برای نتایج غنی (Rich Results)
ابزار اصلی	Schema Markup Validator (متعلق به Schema.org)	Rich Results Test (متعلق به گوگل)
سؤالی که جواب می‌ده	«آیا کدی که نوشتم از نظر ساختاری درسته؟»	«آیا گوگل برای این کد، نتیجه بصری (مثل ستاره) نشون می‌ده؟»
اهمیت برای اسکیمای سفارشی	حیاتی! کد تو باید 100% معتبر باشه.	کم‌اهمیت. اسکیمای سفارشی تو قرار نیست ریچ ریزالت بگیره و این طبیعیه!

اسکیمای سفارشی (Custom Schema) چیست و چرا اعتبارسنجی آن حیاتی است؟

بذار خیلی ساده شروع کنم. حتماً با اسکیمای استاندارد مثل Article (مقاله)، Product (محصول) یا Recipe (دستور پخت) آشنایی داری. این‌ها مثل فرم‌های آماده‌ای هستن که Schema.org در اختیار ما گذاشته تا به گوگل بگیم محتوای صفحه‌مون دقیقاً چیه.

اما اگه کسب‌وکار تو یا محتوایی که تولید می‌کنی اونقدر خاص باشه که توی این قالب‌های استاندارد جا نگیره چی؟ مثلاً فرض کن تو یک سایت تخصصی در مورد «ابزارهای تحلیل ترافیک فضایی» داری! هیچ اسکیمای استانداردی برای این مفهوم وجود نداره.

اینجا دقیقاً جاییه که اسکیمای سفارشی (Custom Schema) وارد می‌شه. اسکیمای سفارشی به تو اجازه می‌ده که فراتر از قالب‌های آماده بری و ویژگی‌ها (Properties) یا حتی انواع (Types) جدیدی رو تعریف کنی که مختص کسب‌وکار تو هستن.

حالا چرا اعتبارسنجی (Validation) اینقدر حیاتیه؟

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

در مورد اسکیما هم همینه. وقتی تو داری یه ساختار «خارج از استاندارد» می‌سازی، ریسک خطا خیلی بالاست. اعتبارسنجی به تو اطمینان می‌ده که این زبان جدیدی که ساختی، حداقل از نظر ساختاری (Syntax) درسته و برای موتورهای جستجو قابل فهمه.

اگه اسکیمای سفارشی تو «نامعتبر» (Invalid) باشه، گوگل در بهترین حالت اون رو نادیده می‌گیره و تمام تلاشت برای متمایز شدن به هدر می‌ره. در بدترین حالت، ممکنه باعث گیج شدن گوگل در تفسیر کل محتوای صفحه‌ات بشه. پس اول اعتبارسنجی، بعد اجرا!

تعریف اسکیمای سفارشی: فراتر از انواع استاندارد Schema.org

وقتی می‌گیم «اسکیمای سفارشی»، منظورمون این نیست که داریم یه چیز جدید از صفر اختراع می‌کنیم و قوانین Schema.org رو کلاً نادیده می‌گیریم. اتفاقاً برعکسه!

ما داریم از پایه‌های اصلی Schema.org (مثل Thing که مادر همه‌ی انواع هست) یا انواع مشخص‌تر (مثل Product) استفاده می‌کنیم و اون رو گسترش (Extend) می‌دیم.

فکر کن Schema.org یه جعبه لگوی استاندارد به تو داده که باهاش می‌تونی «خونه» یا «ماشین» بسازی. اسکیمای سفارشی یعنی تو بری و قطعات لگوی خیلی خاص خودت رو (مثلاً یه قطعه برای «آنتن ماهواره‌ای پیشرفته») طراحی کنی و به اون جعبه اضافه کنی.

در عمل، این یعنی تو می‌تونی:

• ویژگی‌های جدید (New Properties) تعریف کنی: مثلاً اگه یه سایت نقد و بررسی لپ‌تاپ داری، می‌تونی یه ویژگی به اسم keyboardTravelDistance (میزان عمق کلید کیبورد) تعریف کنی که توی اسکیمای استاندارد Product وجود نداره.
• انواع جدید (New Types) بسازی: می‌تونی یه نوع جدید (مثلاً MyCustomTechService) تعریف کنی که ویژگی‌هایی رو از چند نوع استاندارد به ارث می‌بره و چندتا ویژگی جدید و سفارشی هم داره.

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

تفاوت کلیدی: اعتبارسنجی (Validation) در برابر دیباگ کردن (Debugging)

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

۱. اعتبارسنجی (Validation):

• کارش چیه؟ بررسی می‌کنه که آیا کدی که نوشتی از نظر ساختاری و گرامری (Syntax) درسته یا نه.
• به چه سؤالی جواب می‌ده؟ «آیا پرانتزها و براکت‌ها رو درست بستی؟»، «آیا فرمت داده‌ها (مثلاً تاریخ یا عدد) درسته؟»، «آیا اسمی که برای ویژگی انتخاب کردی، مجازه؟»
• ابزارش چیه؟ ابزار اصلی برای این کار Schema Markup Validator (متعلق به خودorg) هست. این ابزار فقط بهت می‌گه کد تو «معتبر» (Valid) هست یا نه. براش مهم نیست گوگل باهاش چی کار می‌کنه.

۲. دیباگ کردن (Debugging) یا عیب‌یابی:

• کارش چیه؟ بررسی می‌کنه که آیا گوگل می‌تونه این اسکیمای «معتبر» رو درک کنه و ازش برای نمایش نتایج غنی (Rich Results) استفاده کنه یا نه.
• به چه سؤالی جواب می‌ده؟ «آیا این اسکیمای Recipe تمام ویژگی‌های لازم (مثل ingredients) برای نمایش به عنوان یه ریچ ریزالت رو داره؟»، «آیا گوگل اصلاً این نوع اسکیما رو می‌شناسه و براش ریچ ریزالتی در نظر گرفته؟»
• ابزارش چیه؟ ابزار Rich Results Test گوگل برای این کاره.

نکته طلایی برای اسکیمای سفارشی:

اسکیمای سفارشی تو همیشه باید در ابزار Schema Markup Validator معتبر باشه. اما به احتمال زیاد، در ابزار Rich Results Test هیچ نتیجه خاصی نشون نمی‌ده (چون گوگل ریچ ریزالتی برای ویژگی «میزان عمق کلید کیبورد» تو نداره!).

پس هدف از اسکیمای سفارشی، گرفتن ریچ ریزالت نیست. هدف، چیزی بسیار بزرگتره که در بخش بعدی بهت می‌گم.

مزایای استفاده از اسکیمای سفارشی برای سئو و گراف دانش (Knowledge Graph)

خب، حالا می‌رسیم به سؤال اصلی: «اگه این همه زحمت بکشم و اسکیمای سفارشی بنویسم ولی ریچ ریزالت نگیرم، پس چه فایده‌ای داره؟»

جواب در یک کلمه است: موجودیت (Entity).

تو با اسکیمای سفارشی، داری مستقیماً به گراف دانش (Knowledge Graph) گوگل اطلاعات تزریق می‌کنی.

۱. تعریف دقیق موجودیت (Entity Definition) تو با این کار به گوگل کمک می‌کنی تا «موجودیت‌های» منحصر به کسب‌وکارت رو بشناسه. مثلاً وقتی برای «ابزار تحلیل ترافیک فضایی» خودت اسکیما می‌سازی، به گوگل می‌گی: «هی گوگل! این یه ‘موجودیت’ جدید و مهمه. اینم ویژگی‌هاش». این کار تو رو به عنوان مرجع (Authority) اون «موجودیت» در کل اینترنت معرفی می‌کنه.

۲. تقویت E-E-A-T (تجربه، تخصص، اعتبار، اعتماد) وقتی تو اینقدر دقیق و ساختاریافته، اطلاعاتی رو ارائه می‌دی که فراتر از دانش عمومیه، داری به قوی‌ترین شکل ممکن تخصص (Expertise) و اعتبار (Authoritativeness) خودت رو به گوگل ثابت می‌کنی. داری سیگنال می‌دی که «من در این حوزه شوخی ندارم و عمیقاً متخصصم.»

۳. کمک به رفع ابهام (Disambiguation) گاهی اوقات اسم محصول، خدمت یا حتی برند تو ممکنه چندمعنایی باشه. اسکیمای سفارشی به گوگل کمک می‌کنه تا دقیقاً بفهمه منظور تو کدوم «موجودیت» هست و چه ارتباطی با موجودیت‌های دیگه در وب داره. (این یعنی سئوی معنایی در خالص‌ترین شکل خودش!)

۴. سرمایه‌گذاری برای آینده (تغذیه گراف دانش) هدف نهایی، وارد کردن اطلاعات منحصر به فرد تو به «گراف دانش» گوگله. وقتی گوگل اطلاعات تو رو درک و تایید کنه، ممکنه در آینده از اونها در فیچرهای پیشرفته‌تری مثل پنل‌های دانش (Knowledge Panels) یا پاسخ‌های مستقیم (Direct Answers) استفاده کنه. تو داری برای سئوی فردای گوگل آماده می‌شی، نه فقط سئوی امروز.

به طور خلاصه، اسکیمای سفارشی ابزار تو برای صحبت مستقیم با مغز گوگل (گراف دانش) و تثبیت خودت به عنوان یک متخصص بی‌رقیب در حوزه‌ی کاریته.

گام اول: اعتبارسنجی سینتکس و ساختار (Validation)

ببین، تو داری با گوگل با یه زبان تخصصی (JSON-LD) صحبت می‌کنی. «اعتبارسنجی» یعنی اینکه مطمئن بشیم «گرامر» و «املای» این زبان رو درست رعایت کردی.

گوگل خیلی روی این موضوع حساسه. اگه کد اسکیمای تو حتی یه ویرگول (,) یا یه براکت (}) رو کم داشته باشه، گوگل اصلاً به خودش زحمت نمی‌ده که بفهمه منظور تو چی بوده. کل اون تیکه کد رو نادیده می‌گیره.

پس فرقی نداره چقدر مفهوم اسکیمای سفارشی تو هوشمندانه باشه؛ اگه از نظر ساختاری (Syntax) معتبر (Valid) نباشه، انگار اصلاً وجود نداره. پس قبل از اینکه کد رو روی سایتت منتشر کنی، باید از فیلتر اعتبارسنجی ردش کنی.

معرفی ابزار Schema Markup Validator (ابزار رسمی Schema.org)

برای اینکه مطمئن بشیم گرامرمون درسته، باید از ابزار رسمی خودِ صاحب‌خونه استفاده کنیم. Schema Markup Validator (که قبلاً بخشی از ابزار گوگل بود اما حالا خود Schema.org مدیریتش می‌کنه) دقیقاً برای همین کاره.

این ابزار، تنها مرجع رسمی برای بررسی «اعتبار ساختاری» کد اسکیمای توئه. کار این ابزار این نیست که بهت بگه آیا ریچ ریزالت (Rich Result) می‌گیری یا نه؛ کارش اینه که بهت بگه آیا کدی که نوشتی، «درست» و «قابل فهم» هست یا نه. برای اسکیمای سفارشی، این تنها ابزار اعتبارسنجی مورد نیاز ماست.

چگونه کدهای JSON-LD سفارشی خود را اعتبارسنجی کنیم؟

کار با این ابزار به طرز خوشایندی ساده‌ است. بذار مرحله به مرحله بهت بگم:

۱. رفتن به ابزار: اول از همه، به وب‌سایت validator.schema.org برو.

۲. انتخاب روش: تو دو تا گزینه داری: * FETCH URL (گرفتن URL): می‌تونی آدرس صفحه‌ای از سایتت که اسکیما روش نصبه رو بدی. * CODE SNIPPET (تکه کد): می‌تونی مستقیماً کد JSON-LD خودت رو در باکسی که وجود داره کپی-پیست کنی.

۳. توصیه من: وقتی داری یه اسکیمای سفارشی جدید می‌نویسی، همیشه اول از گزینه‌ی Code Snippet استفاده کن. کد JSON-LD خودت رو (همونی که با <script type=”application/ld+json”> شروع می‌شه) کامل کپی کن و اونجا پیست کن.

۴. اجرای تست: دکمه‌ی «RUN TEST» رو بزن.

۵. بررسی نتایج: در چند ثانیه، ابزار نتیجه رو در سمت راست صفحه بهت نشون می‌ده. اینجاست که باید حواست رو جمع کنی تا ببینی «خطا» داری یا «هشدار».

درک خطاها (Errors) در برابر هشدارها (Warnings) در Validator

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

• خطاها (Errors):
  • این‌ها با رنگ قرمز و علامت ضربدر ❌ مشخص می‌شن.
  • معنی: گرامر کد تو اساساً اشتباهه. مثلاً یه ویرگول رو جا انداختی، یه براکت ({}) رو نبستی، یا از یه ویژگی (Property) استفاده کردی که اصلاً در کتابخونهorg تعریف نشده (و تو هم اون رو به درستی به عنوان یه ویژگی سفارشی تعریف نکردی).
  • اقدام لازم: حیاتی! اسکیمای تو در حال حاضر «نامعتبر» (Invalid) هست و گوگل اون رو نادیده خواهد گرفت. تو باید تمام خطاها رو قبل از انتشار، رفع کنی.
• هشدارها (Warnings):
  • این‌ها با رنگ نارنجی و علامت تعجب ⚠️ مشخص می‌شن.
  • معنی: کد تو از نظر ساختاری «معتبر» (Valid) هست، اما… ابزار داره بهت می‌گه: «بهتر بود از فلان ویژگی پیشنهادی (Recommended) هم استفاده می‌کردی».
  • اقدام لازم (مخصوص اسکیمای سفارشی): وقتی داری اسکیمای سفارشی می‌نویسی، گرفتن هشدار کاملاً طبیعیه! چرا؟ چون تو داری ویژگی‌هایی (مثلاً keyboardTravelDistance) تعریف می‌کنی که این ابزار اون‌ها رو به عنوان بخشی از استاندارد نمی‌شناسه و فقط بهت هشدار می‌ده.
  • قانون طلایی: در اعتبارسنجی اسکیمای سفارشی، هدف ما صفر کردن خطاها (Errors) است، نه لزوماً صفر کردن هشدارها (Warnings). تا زمانی که خطا نداری، کد تو «معتبر» محسوب می‌شه.

اعتبارسنجی Microdata و RDFa در مقایسه با JSON-LD

یادته گفتم JSON-LD روش ترجیحی ماست؟ دو تا روش قدیمی‌تر هم برای پیاده‌سازی اسکیما وجود داره:

• Microdata: استفاده از تگ‌های itemscope، itemtype و itemprop مستقیماً در داخل کدهای
• RDFa: شبیه به Microdata اما با استفاده از ویژگی‌هایی مثل vocab، typeof و property.

تفاوت در اعتبارسنجی:

ابزار Schema Markup Validator هر سه فرمت رو می‌تونه اعتبارسنجی کنه. اما اعتبارسنجی Microdata و RDFa ذاتاً سخت‌تره.

چرا؟ چون این کدها با کدهای HTML صفحه‌ی تو قاطی شدن. یه تگ <div> که درست بسته نشده یا یه تداخل ساده در تگ‌های HTML می‌تونه باعث بشه کل ساختار اسکیمای تو نامعتبر بشه. پیدا کردن خطا در این حالت مثل پیدا کردن سوزن در انبار کاهه.

برتری JSON-LD:

اما JSON-LD مثل یه جزیره‌ی جداست. یه بلوک کد تر و تمیزه که معمولاً در <head> یا انتهای <body> قرار می‌گیره و کاری به کار بقیه‌ی کدهای HTML تو نداره.

اعتبارسنجی‌اش خیلی راحته. کپی-پیست می‌کنی توی Validator، اگه خطا داشت، همونجا توی کد JSON-LD خودت درستش می‌کنی و تمام. به همین دلیله که برای کارهای پیشرفته و سفارشی‌سازی، تقریباً همه‌ی متخصص‌ها (از جمله من) فقط و فقط JSON-LD رو توصیه می‌کنن.

گام دوم: دیباگ کردن برای پشتیبانی گوگل و نتایج غنی (Debugging)

«اعتبارسنجی» (گام ۱) به ما گفت که آیا زبان ما از نظر گرامری درسته یا نه. اما «دیباگ کردن» (گام ۲) به ما می‌گه که آیا گوگل اصلاً قصد داره بر اساس حرفی که ما زدیم، یه اقدام خاص (یعنی نمایش نتایج غنی یا Rich Results) انجام بده یا نه.

فکر کن تو به زبان اسپانیایی کاملاً بی‌نقص، آدرس یه رستوران عالی رو از یه نفر پرسیدی (اعتبارسنجی ✅). اما اون شخص، توریسته و اصلاً اسپانیایی بلد نیست! درسته که تو حرفت رو درست زدی، ولی اون نمی‌تونه «پردازش» کنه و جوابی که تو می‌خوای (آدرس رستوران) رو بهت بده.

ابزار دیباگ گوگل هم دقیقاً همین کار رو می‌کنه: به تو می‌گه که آیا می‌تونه برای اسکیمای تو، یه نتیجه بصری جذاب در صفحه نتایج (مثل ستاره‌های امتیاز، قیمت، یا زمان پخت) نشون بده یا نه.

کار با ابزار Rich Results Test گوگل

ابزار اصلی ما در این مرحله، Rich Results Test هست که مستقیماً توسط خود گوگل ارائه می‌شه. این ابزار دقیقاً به ما نشون می‌ده که ربات گوگل چه برداشتی از اسکیمای ما داره.

نحوه کار باهاش دقیقاً مثل ابزار قبلیه:

۱. به ابزار Rich Results Test در پلتفرم Google Search Central برو. ۲. می‌تونی URL صفحه‌ای که اسکیما روش نصبه رو بدی (گزینه پیشنهادی برای تست نهایی) یا مستقیماً تکه کد JSON-LD خودت رو در بخش Code پیست کنی. ۳. دکمه «Test Code» (یا «Test URL») رو بزن.

این ابزار، برخلاف Validator قبلی، اصلاً کاری نداره که تو از ویژگی‌های سفارشی استفاده کردی یا نه. اون فقط دنبال یه چیز می‌گرده: «آیا این صفحه، ویژگی‌های لازم برای نمایش به عنوان یکی از انواع نتایج غنی که من (گوگل) پشتیبانی می‌کنم رو داره یا نه؟»

چرا اسکیمای سفارشی من در Rich Results Test پشتیبانی نمی‌شود؟

اینجا دقیقاً همون‌جاییه که خیلی‌ها گیج می‌شن و ناامید می‌شن. تو اسکیمای سفارشی بی‌نظیرت رو (که در گام اول «معتبر» شده) در این ابزار می‌ذاری و با پیام‌هایی مثل «Page is not eligible for rich results» (صفحه واجد شرایط نتایج غنی نیست) یا چیزی شبیه به اون مواجه می‌شی.

آیا تو کار اشتباهی کردی؟ مطلقاً نه!

این کاملاً طبیعی و مورد انتظار است.

یادت باشه، تو یه ویژگی سفارشی مثل keyboardTravelDistance (عمق کلید کیبورد) تعریف کردی. خب، گوگل که (فعلاً) هیچ «نتیجه غنی» یا «ویژگی بصری» خاصی در نتایج جستجو برای «عمق کلید کیبورد» نداره!

پس ابزار Rich Results Test خیلی صادقانه به تو می‌گه: «کدی که دادی معتبره، منم فهمیدمش، ولی من هیچ ریچ ریزالتی برای این نوع داده پشتیبانی نمی‌کنم که بخوام بهت نشون بدم.»

نکته کلیدی: شکست خوردن در Rich Results Test به معنی بی‌فایده بودن اسکیمای سفارشی تو نیست. یادت نره، هدف اصلی ما از اسکیمای سفارشی، «گرفتن ریچ ریزالت» نبود؛ بلکه «تغذیه گراف دانش (Knowledge Graph)» و «اثبات تخصص (E-E-A-T)» بود.

توسعه (Extending) انواع موجود گوگل (مانند Product یا LocalBusiness)

خب، حالا سؤال هوشمندانه اینه: «پس چطور هم از مزایای ریچ ریزالت‌های استاندارد گوگل بهره‌مند بشم و هم اطلاعات سفارشی خودم رو به گراف دانش بدم؟»

جواب: توسعه دادن (Extending).

تو نباید یه اسکیما رو از صفر اختراع کنی. هوشمندانه‌ترین کار اینه که یکی از انواع اسکیمای «استاندارد» و «پشتیبانی‌شده» توسط گوگل (مثل Product, LocalBusiness, Article) رو به عنوان پایه انتخاب کنی و بعد، ویژگی‌های سفارشی خودت رو به اون «اضافه» کنی.

بیا یه مثال دقیق بزنیم:

فرض کن می‌خوای برای همون لپ‌تاپ، اسکیما بزنی.

۱. پایه (استاندارد): تو با اسکیمای Product شروع می‌کنی. تمام ویژگی‌های لازم برای گرفتن ریچ ریزالت محصول (مثل name، image، و offers) رو با دقت پر می‌کنی. ۲. توسعه (سفارشی): حالا، در ادامه‌ی همون کد JSON-LD و در داخل همون براکت‌های Product، ویژگی سفارشی خودت رو هم اضافه می‌کنی: “keyboardTravelDistance”: “1.5mm”

نتیجه چی می‌شه؟

• وقتی این کد رو در Rich Results Test اجرا می‌کنی، ابزار به ویژگی‌های name و offers نگاه می‌کنه و می‌گه: «عالیه! این یه اسکیمای Product معتبره و واجد شرایط ریچ ریزالت محصوله!»
• ابزار، ویژگی سفارشی تو (keyboardTravelDistance) رو می‌بینه، ولی چون ریچ ریزالتی براش نداره، خیلی ساده اون رو نادیده می‌گیره (ولی خطا هم نمی‌ده!).
• اتفاق اصلی: ربات گوگل موقع خزش صفحه، کل اسکیما رو می‌خونه. بخش استانداردش رو برای ریچ ریزالت استفاده می‌کنه، و بخش سفارشی (keyboardTravelDistance) رو مستقیماً به گراف دانش خودش می‌فرسته تا درک عمیق‌تری از این «موجودیت» (لپ‌تاپ) به دست بیاره.

این یعنی تو با یه تیر دو نشون زدی!

بررسی گزارش‌های Google Search Console برای خطاهای اسکیمای شناسایی‌شده

کارت هنوز تموم نشده. بعد از اینکه کد رو اعتبارسنجی کردی، با Rich Results Test هم دیباگ کردی و روی سایتت منتشرش کردی، باید ببینی گوگل در عمل باهاش چی کار می‌کنه.

اینجا گوگل سرچ کنسول (Google Search Console) وارد می‌شه.

۱. بعد از اینکه گوگل صفحات تو رو کرال کرد، به بخش Enhancements (بهبودها) در منوی سرچ کنسول برو. ۲. تو در این بخش، گزارش‌هایی رو برای تمام انواع اسکیمایی که گوگل براشون ریچ ریزالت پشتیبانی می‌کنه، می‌بینی (مثل Products, FAQs, Recipes, …). ۳. روی گزارش مربوطه (مثلاً Products) کلیک کن.

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

• Error (خطا): این‌ها صفحاتی هستن که اسکیمای Product دارن، ولی یه مشکل «اساسی» (مثل نداشتن فیلد offers) دارن. این صفحات هیچ ریچ ریزالتی دریافت نمی‌کنن و تو باید «فوراً» این خطاها رو رفع کنی.
• Valid with warnings (معتبر با هشدار): این‌ها بهترین حالت ممکن هستن. یعنی اسکیمای تو درسته و ریچ ریزالت رو می‌گیری، اما گوگل «توصیه» می‌کنه که یه سری فیلد پیشنهادی (مثل brand یا review) رو هم اضافه کنی تا کامل‌تر بشه.
• Valid (معتبر): یعنی همه‌چیز عالیه و ریچ ریزالت رو داری.

نکته مهم در مورد اسکیمای سفارشی:

سرچ کنسول هیچ گزارشی در مورد ویژگی سفارشی تو (keyboardTravelDistance) بهت نمی‌ده. چون اصلاً «بهبودی» (Enhancement) برای اون تعریف نشده.

پس تو از سرچ کنسول استفاده می‌کنی تا مطمئن بشی که «پایه‌ی» اسکیمات (همون Product) سالمه و داره ریچ ریزالت می‌گیره. بخش سفارشی، خوراک پشت پرده‌ی گراف دانش گوگله که ما در گام اول (Validator) از «معتبر» بودنش مطمئن شدیم.

رایج‌ترین خطاها در هنگام ایجاد و اعتبارسنجی اسکیمای سفارشی (تجربه عملی)

من صدها اسکیما رو بررسی و عیب‌یابی کردم. تقریباً ۹۰ درصد مشکلات، به همین چند موردی که بهت می‌گم برمی‌گرده. این‌ها جزئیات کوچیکی هستن که بزرگترین دردسرها رو درست می‌کنن.

خطاهای نحوی (Syntax Errors): کاما، براکت یا آکولاد جا افتاده

باور کن یا نه، رایج‌ترین و در عین حال پایه‌ای‌ترین مشکل همینه! JSON-LD (فرمت پیشنهادی ما) به شدت به نحو (Syntax) حساسه. اون مثل یه معلم گرامر سخت‌گیره که یه «ویرگول» جا افتاده رو هم نمی‌بخشه.

تجربه‌ی عملی من:

• کاما (,): رایج‌ترین اشتباه! یادت باشه، در JSON، هر جفت «کلید: مقدار» (key: value pair) باید با کاما از جفت بعدی جدا بشه. اما مهم‌تر از اون، آخرین جفت در یک لیست یا آبجکت، نباید کاما داشته باشه.
  • مثال خطا:

{

“@type”: “Product”,

“name”: “محصول من”,  // <– این کاما اینجا لازمه

“description”: “توضیحات عالی” // <– این کاما در انتها «خطا» ایجاد می‌کنه!

}

• براکت‌ها ([]) و آکولادها ({}): هر آکولادی ({) که باز می‌کنی، باید دقیقاً یه آکولاد (}) برای بستنش وجود داشته باشه. اگه یه موجودیت رو داخل یه موجودیت دیگه (Nesting) تعریف می‌کنی، حواست به این باز و بسته شدن‌ها باید دو برابر باشه.

راه‌حل: اصلاً سعی نکن این‌ها رو چشمی پیدا کنی. همونطور که در گام اول گفتم، قبل از هر کاری، کدت رو در Schema Markup Validator کپی-پیست کن. این ابزار دقیقاً بهت می‌گه که در خط چندم، کدوم کاما یا براکت رو جا انداختی.

تعریف نادرست @context و @type

این دو تا، «پایه‌ی» کل اسکیمای تو هستن. اگه این‌ها اشتباه باشن، کل ساختمون اسکیمات فرو می‌ریزه.

• @context (فرهنگ لغت):
  • این به گوگل می‌گه که از کدوم «فرهنگ لغت» برای خوندن کدهای تو استفاده کنه.
  • خطای رایج: نوشتن http://schema.org (بدون s) یا اشتباه املایی در خود org.
  • شکل درست: تقریباً در همه‌ی موارد، باید این باشه: “@context”: “https://schema.org”
• @type (نوع موجودیت):
  • این به گوگل می‌گه که داری در مورد «چی» صحبت می‌کنی (مقاله؟ محصول؟).
  • خطای رایج: اشتباه املایی. من به تجربه خیلی دیدم که به جای Article می‌نویسن Artical یا به جای LocalBusiness می‌نویسن LocalBuisness.
  • خطای سفارشی‌سازی: وقتی می‌خوای یه نوع «سفارشی» بسازی، نباید یه اسم کاملاً من‌درآوردی استفاده کنی. تو باید از یه نوع «پایه» (مثل Thing یا Product) ارث‌بری کنی. اگه یه نوع کاملاً جدید تعریف کنی که به org متصل نباشه، گوگل اصلاً نمی‌فهمه این چیه.

استفاده از ویژگی‌های (Properties) نامعتبر برای یک نوع (Type) خاص

این یه اشتباه خیلی تخصصی‌تره. هر @type (نوع) در Schema.org، مجموعه‌ی مشخصی از «ویژگی‌ها» (Properties) رو قبول می‌کنه.

مثال ملموس:

تو نمی‌تونی ویژگی ingredients (مواد لازم) رو که مخصوص اسکیمای Recipe (دستور پخت) هست، برداری و برای اسکیمای Article (مقاله) استفاده کنی! این مثل اینه که بخوای در فرم ثبت‌نام خودرو، گزینه‌ی «گروه خونی» رو پر کنی. کاملاً بی‌ربطه.

خطای رایج در عمل:

من دیدم که شخصی می‌خواد برای Article، نویسنده (author) تعریف کنه، اما به جای استفاده از ویژگی author، از ویژگی publisher (که معمولاً برای Organization به کار می‌ره) استفاده می‌کنه و انتظار داره گوگل متوجه بشه.

نکته اسکیمای سفارشی:

وقتی تو یه ویژگی سفارشی (مثل keyboardTravelDistance برای Product) اضافه می‌کنی، ابزار Validator بهت «هشدار» (Warning) می‌ده (که گفتیم طبیعیه). اما اگه از یه ویژگی «استاندارد» ولی «بی‌ربط» (مثل ingredients برای Article) استفاده کنی، ابزار بهت «خطا» (Error) می‌ده، چون این ویژگی برای اون نوع تعریف نشده.

عدم اتصال صحیح موجودیت‌ها (Nesting یا استفاده از @id)

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

سناریوی خطا:

فرض کن یه صفحه مقاله (Article) داری که نویسنده‌اش (Person) یه شخص خاصه، و اون مقاله در مورد یه محصول (Product) صحبت می‌کنه.

• کار اشتباه: تو سه تا بلوک <script> جدا برای Article، Person و Product در صفحه می‌ذاری. خب، گوگل حالا سه تا «موجودیت» جدا می‌بینه. اون از کجا باید بفهمه که این Person، نویسنده‌ی اون Article هست و اون Article داره اون Product رو نقد می‌کنه؟

راه‌حل‌های درست (که اغلب اشتباه پیاده‌سازی می‌شن):

۱. تو در تو کردن (Nesting): ساده‌ترین راه اینه که موجودیت‌های مرتبط رو «داخل» همدیگه تعریف کنی.

• مثال درست:

{

“@type”: “Article”,

“headline”: “نقد محصول X”,

“author”: {

“@type”: “Person”,

“name”: “نام و نام خانوادگی” // <– موجودیت Person داخل Article

},

“about”: {

“@type”: “Product”,

“name”: “محصول X” // <– موجودیت Product داخل Article

}

}

• خطای رایج در Nesting: فراموش کردن آکولادهای ({}) داخلی یا تعریف نادرست نوع.

۲. استفاده از @id (روش حرفه‌ای): وقتی روابط پیچیده می‌شه، Nesting کثیف‌کاری می‌کنه. اینجا ما به هر موجودیت یه «شناسه» (ID) منحصربه‌فرد می‌دیم و اون‌ها رو به هم «لینک» می‌کنیم.

• خطای رایج: استفاده از URL به عنوان @id بدون اینکه اون URL خودش یه موجودیت تعریف‌شده باشه. یا بدتر از اون، عدم استفاده از @id و رها کردن چند موجودیت در صفحه به امید اینکه گوگل خودش روابط رو حدس بزنه! (که معمولاً حدس نمی‌زنه).

توصیه عملی من: همیشه سعی کن با Nesting شروع کنی. اگر دیدی یه موجودیت (مثلاً Person) قراره در چند جای دیگه هم استفاده بشه، براش یه @id (مثلاً @id: “#sahar-bahrani”) تعریف کن و در جاهای دیگه فقط به اون ID ارجاع بده. این کار کد تو رو تمیز و فهم اون رو برای گوگل قطعی می‌کنه.

بهترین شیوه‌ها (Best Practices) برای ایجاد اسکیمای سفارشی قابل اعتماد

وقتی از «قابل اعتماد» حرف می‌زنیم، منظورمون فقط «بدون خطا» بودن (Valid) نیست. منظورمون اینه که اسکیمای ما اونقدر هوشمندانه، تمیز و استراتژیک طراحی شده باشه که گوگل اون رو به عنوان یه منبع اطلاعاتی «موثق» قبول کنه. این کار یه هنره که تو هم می‌تونی یاد بگیریش.

اولویت‌بندی: توسعه انواع موجود به جای ایجاد نوع کاملاً جدید

این مهم‌ترین قانون منه. هیچ‌وقت چرخ رو از اول اختراع نکن!

منظورم چیه؟ ببین، کتابخونه Schema.org هزاران نوع (Type) از قبل تعریف‌شده داره (مثل Product, Service, Article, LocalBusiness). گوگل این‌ها رو کاملاً می‌شناسه، بهشون اعتماد داره و برای خیلی‌هاشون «نتایج غنی» (Rich Results) هم در نظر گرفته.

• کار اشتباه (که خیلیا انجام می‌دن): می‌خوان یه «خدمت آموزشی» رو معرفی کنن، به جای استفاده از Service یا Course، یه نوع کاملاً جدید به اسم MySuperEducationalService از ریشه‌ی Thing می‌سازن. خب گوگل این رو می‌بینه و می‌گه: «جالبه… ولی من اصلاً نمی‌دونم این چیه و باید باهاش چی کار کنم!»
• کار درست (Best Practice):
  1. از خودت بپرس: «نزدیک‌ترین نوع استانداردی که گوگل می‌شناسه چیه؟» مثلاً Product یا Service یا Course.
  2. همون نوع استاندارد رو به عنوان پایه انتخاب کن.
  3. تمام ویژگی‌های استاندارد و پیشنهادی گوگل برای اون نوع رو کامل پر کن (تا شانس ریچ ریزالت رو از دست ندی).
  4. حالا، ویژگی‌های «سفارشی» و منحصر به فرد خودت رو به همین نوع پایه «اضافه» کن.

اینطوری تو با یه تیر دو نشون می‌زنی: هم از اعتماد و ریچ ریزالت‌های استاندارد گوگل بهره می‌بری، و هم اطلاعات تخصصی و سفارشی خودت رو برای تغذیه گراف دانش بهش می‌دی.

استفاده از @id برای تعریف یک موجودیت منحصربه‌فرد و جلوگیری از تکرار

این یه تکنیک فوق‌العاده حرفه‌ای برای مدیریت «موجودیت‌ها» (Entities) در سایته.

مشکل: فرض کن تو «سارا بحرانی» هستی. یه صفحه «درباره من» (Person) داری. ۲۰ تا مقاله (Article) هم به عنوان نویسنده (author) نوشتی. اگه توی هر ۲۰ تا مقاله، اطلاعات «سارا بحرانی» (اسم، شغل، لینک وب‌سایت) رو از اول بنویسی، گوگل از کجا باید مطمئن بشه این ۲۰ تا «سارا بحرانی» دقیقاً یک نفر هستن؟

راه‌حل (@id): تو باید به هر موجودیت کلیدی سایتت یه «شناسه» یا کد ملی منحصربه‌فرد (@id) بدی.

1. در صفحه «درباره من»، اسکیمای Person خودت رو اینطوری تعریف می‌کنی:

{

“@type”: “Person”,

“@id”: “https://vazirseo.com/#sara-bahrani”, // <– این شناسنامه توئه

“name”: “سارا بحرانی”,

“jobTitle”: “کارشناس ارشد سئو”

}

حالا، توی اسکیمای هر کدوم از اون ۲۰ تا مقاله، به جای تعریف دوباره‌ی نویسنده، فقط به اون «شناسنامه» ارجاع می‌دی:

{

“@type”: “Article”,

“headline”: “راهنمای اسکیمای سفارشی”,

“author”: {

“@id”: “https://vazirseo.com/#sara-bahrani” // <– «نویسنده این مقاله، همون نفریه که اونجا تعریفش کردم»

}

}

فایده‌ش چیه؟ تو داری به گوگل کمک می‌کنی تا یه نقشه‌ی تمیز و دقیق از موجودیت‌های سایتت بسازه. گوگل با اطمینان کامل می‌فهمه که این «شخص» نویسنده‌ی اون «مقاله»هاست و همه‌ی این‌ها به هم متصلن. این کار به شدت «اعتبار» (Authoritativeness) تو رو در گراف دانش گوگل محکم می‌کنه.

مستندسازی داخلی اسکیمای سفارشی برای تیم توسعه

این یه نکته‌ی غیرفنی اما به شدت حیاتیه که از تجربه‌ی عملی میاد.

تو به عنوان متخصص سئو، یه اسکیمای سفارشی عالی مثلاً برای Product با ویژگی customWarrantyPeriod طراحی می‌کنی. اون رو می‌دی به تیم فنی. تیم فنی همون رو اجرا می‌کنه.

شش ماه بعد، یه برنامه‌نویس جدید به تیم اضافه می‌شه. اون داره کدهای سایت رو «تمیزکاری» می‌کنه که یهو به کد اسکیمای تو می‌رسه. از اونجایی که نمی‌دونه customWarrantyPeriod چیه و چرا وجود داره، فکر می‌کنه یه کد «اضافی» یا «اشتباه» قدیمیه و… پاکش می‌کنه!

تمام زحمات تو به باد می‌ره.

راه‌حل (Best Practice): تو باید یه سند مستندسازی (Documentation) ساده و قابل فهم برای تیم فنی درست کنی. یه فایل Google Doc یا یه صفحه در پلتفرم مدیریت پروژه (مثل جیرا یا تسکولو) کافیه.

در این سند برای هر ویژگی سفارشی که می‌سازی، بنویس:

• ویژگی (Property): customWarrantyPeriod
• روی چه نوعی اعمال می‌شه؟ Product
• معنیش چیه؟ «دوره‌ی گارانتی سفارشی که ما ارائه می‌دیم.»
• چرا مهمه؟ (اینو برای مدیر محصول و برنامه‌نویس می‌نویسی): «این یه سیگنال E-A-T برای گوگله که نشون می‌ده ما فراتر از استانداردها خدمات می‌دیم و نباید حذف بشه.»

این کار باعث می‌شه استراتژی سئوی تو در برابر تغییرات تیم فنی، مقاوم بشه.

چگونه اسکیمای سفارشی، تخصص (Expertise) و مرجعیت (Authoritativeness) شما را اثبات می‌کند؟

حالا رسیدیم به شاه‌بیت غزل! چرا اصلاً این همه به خودمون زحمت می‌دیم؟

جواب: E-A-T (تخصص، مرجعیت، اعتماد).

ببین، گوگل داره تمام تلاشش رو می‌کنه که «متخصص‌ها» رو از «مقلدها» تشخیص بده.

• سایت مقلد (رقیب تو): یه مقاله در مورد «نقد لپ‌تاپ X» می‌نویسه و فقط اطلاعات عمومی (اندازه صفحه، CPU، رم) رو لیست می‌کنه. اسکیمایی هم که استفاده می‌کنه، همون اسکیمای Product ساده‌اس.
• سایت تو (متخصص): تو همون مقاله رو می‌نویسی. علاوه بر اطلاعات عمومی، میای سه تا پارامتر فوق تخصصی رو هم بررسی می‌کنی: «میزان نیت روشنایی صفحه (Nits)»، «میزان عمق کلید کیبورد (Travel Distance)» و «امتیاز تعمیرپذیری (Repairability Score)».

حالا، تو برای اینکه به گوگل «ثابت» کنی که این تحلیل عمیق رو انجام دادی، میای و اسکیمای Product رو **توسعه» (Extend) می‌دی و این سه تا ویژگی سفارشی رو هم به صورت داده‌ی ساختاریافته (Structured Data) بهش اضافه می‌کنی.

اتفاقی که می‌افته: گوگل وقتی صفحه‌ی تو رو کرال می‌کنه، نه تنها متن رو می‌خونه، بلکه این داده‌های ساختاریافته رو هم می‌بینه. می‌گه: «وای! این سایت (سایت تو) نه تنها در مورد لپ‌تاپ X نوشته، بلکه اونقدر «متخصص» (Expert) بوده که پارامترهایی رو اندازه‌گیری و گزارش کرده که هیچ‌کس دیگه‌ای گزارش نکرده.»

تو با این کار، داری به زبان خودِ گوگل (یعنی زبان داده‌های ساختاریافته) بهش سیگنال می‌دی که تو یک «مرجع» (Authority) در این حوزه هستی. تو فقط اطلاعات رو کپی نمی‌کنی؛ تو اطلاعات «جدید» و «ارزشمند» خلق می‌کنی.

این دقیقاً همون چیزیه که گوگل در آپدیت «محتوای مفید» (Helpful Content) دنبالشه و اسکیمای سفارشی، فنی‌ترین و قوی‌ترین ابزار تو برای اثبات این موضوعه.

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

گاهی اوقات مشکل از خودِ اسکیما نیست؛ مشکل از «چگونه بارگذاری شدن» اون اسکیمائه. ابزارهای استاندارد گوگل (مثل Rich Results Test) عالی هستن، اما گاهی ما نیاز به یه بررسی سریع‌تر یا عمیق‌تر روی خودِ مرورگر داریم.

استفاده از افزونه‌های مرورگر (مانند SEO Pro Extension) برای بررسی سریع

فرض کن می‌خوای به سرعت ببینی ۵ تا از صفحات رقیبت اصلاً از اسکیما استفاده کردن یا نه. باز کردن Rich Results Test برای تک‌تک اون‌ها خیلی وقت‌گیره.

اینجاست که افزونه‌های مرورگر (Browser Extensions) وارد می‌شن. ابزارهای زیادی برای این کار هستن (مثل SEO Pro Extension، Detailed SEO Extension و…)

این افزونه‌ها چطور به تو کمک می‌کنن؟

1. بررسی در لحظه: تو در همون صفحه‌ای که هستی، با یه کلیک روی آیکون افزونه، می‌تونی تب Schema رو باز کنی.
2. تشخیص سریع: این ابزارها فوراً به تو می‌گن که آیا در این صفحه، کد JSON-LD، Microdata یا RDFa پیدا شده یا نه.
3. نمایش درختی: بهترین بخشش اینه که کدهای اسکیما رو به صورت یه ساختار درختی تمیز و خوانا بهت نشون می‌دن. می‌تونی ببینی چه typeهایی استفاده شده و چه propertyهایی زیرمجموعه‌ی اون‌ها هستن.

نکته‌ی مهم: یادت باشه، این افزونه‌ها کارشون «اعتبارسنجی» (Validation) نیست. اون‌ها فقط «پیدا می‌کنن» و «نمایش می‌دن». اما برای مهندسی معکوس سریع رقبا یا یه بررسی آنی قبل از تست نهایی، هیچ‌چیزی سریع‌تر از این‌ها نیست.

تست اسکیمای پیاده‌سازی شده از طریق Google Tag Manager (GTM)

این یکی از بزرگترین تله‌های فنیه! خیلی از تیم‌ها ترجیح می‌دن اسکیما رو مستقیماً در HTML صفحه نذارن، بلکه اون رو از طریق «گوگل تگ منیجر» (GTM) به صفحه «تزریق» (Inject) کنن.

مشکل کجاست؟ اسکیمایی که با GTM میاد، معمولاً «سمت کاربر» (Client-Side) رندر می‌شه. یعنی اول صفحه‌ی خالی میاد، بعد جاوا اسکریپتِ GTM اجرا می‌شه و اسکیما رو به صفحه اضافه می‌کنه.

چطور دیباگش کنیم؟

1. آیا گوگل اصلاً می‌بینتش؟ خوشبختانه، ابزارهای جدید گوگل (مثل Rich Results Test و URL Inspection) می‌تونن جاوا اسکریپت رو رندر کنن. پس اولین قدم اینه که URL صفحه‌ات رو (نه کد رو) در Rich Results Test تست کنی.
2. اگر RRT اون رو ندید چی؟ این یعنی یه مشکلی در اجرای GTM تو هست. ممکنه تگ تو درست فایر (Fire) نمی‌شه یا تریگر (Trigger) تو اشتباهه.
3. تست در GTM: باید از حالت Preview خود GTM استفاده کنی. وارد صفحه‌ات شو، ببین آیا تگِ اسکیمای تو در پنل GTM فایر شده؟ آیا متغیرهایی که اطلاعات رو (مثل نام محصول) به اسکیما پاس می‌دن، درست پر شدن؟

توصیه‌ی من: تا جایی که می‌تونی، اسکیماهای حیاتی (مثل محصول یا مقاله) رو به صورت «سمت سرور» (Server-Side) و مستقیماً در HTML بذار. GTM رو برای کارهای پیچیده‌تر یا مواردی که دسترسی به سورس‌کد نداری، نگه دار.

بررسی خروجی DOM رندر شده (Rendered DOM) برای اطمینان از بارگذاری اسکیما

این دیگه تهِ خطِ دیباگ کردنه!

• HTML Source: کدیه که سرور تو در لحظه‌ی اول می‌فرسته (اگه Ctrl+U بزنی می‌بینیش).
• Rendered DOM: کدیه که «بعد از» اجرای تمام جاوا اسکریپت‌ها (مثل کدهای GTM) در مرورگر کاربر (و ربات گوگل) ساخته می‌شه.

چرا مهمه؟ اسکیمای تو باید در DOM رندر شده وجود داشته باشه.

چطور چکش کنیم؟

1. ابزار Google URL Inspection در سرچ کنسول: این بهترین ابزاره. URL رو اینسپکت کن و روی “Test Live URL” کلیک کن. بعد از اتمام تست، گزینه‌ی “View Tested Page” رو بزن و به تب “HTML” برو. این HTML، دقیقاً DOM رندر شده از دید گوگله. حالا می‌تونی Ctrl+F بزنی و دنبال ld+json یا @type خودت بگردی تا ببینی اصلاً بارگذاری شده یا نه.
2. ابزار Inspect مرورگر (ساده): در صفحه‌ی خودت راست‌کلیک کن و “Inspect” رو بزن. در تبی که باز می‌شه (Elements)، کدی که می‌بینی همون DOM رندر شده‌ است. می‌تونی اونجا هم جستجو کنی. اما یادت باشه، ابزار سرچ کنسول ارجحیت داره چون دقیقاً بهت می‌گه گوگل چی دیده.

اگه اسکیمای تو در سورس HTML هست (SSR)، خیالت راحته. اگه نیست (CSR/GTM)، باید حتماً مطمئن بشی که در DOM رندر شده‌ی گوگل ظاهر می‌شه.

نتیجه‌گیری: از اعتبارسنجی تا نمایش در نتایج جستجو

خب، تبریک می‌گم! تو یه سفر کامل رو در دنیای پیشرفته‌ی اسکیما، از مبتدی تا حرفه‌ای، با من همراه بودی.

بیا یه جمع‌بندی سریع از کل فرآیند داشته باشیم:

1. ایده و استراتژی: اول تصمیم می‌گیریم که برای اثبات تخصص (E-A-T) و کمک به گراف دانش، نیاز به اسکیمای سفارشی داریم. (مثلاً keyboardTravelDistance برای Product).
2. توسعه (Extending): به جای اختراع چرخ، یه نوع استاندارد (مثل Product) رو به عنوان پایه انتخاب می‌کنیم و ویژگی سفارشی رو بهش «اضافه» می‌کنیم.
3. گام ۱: اعتبارسنجی (Validation): قبل از هر کاری، کد JSON-LD رو در Schema Markup Validator می‌ذاریم. هدف ما: صفر کردن خطاها (Errors). (هشدارهای مربوط به بخش سفارشی طبیعیه).
4. گام ۲: دیباگ کردن (Debugging): کد «معتبر» شده رو در Rich Results Test می‌ذاریم. هدف ما: مطمئن بشیم که بخش «استاندارد» (همون Product) واجد شرایط ریچ ریزالته. (این ابزار بخش سفارشی ما رو نادیده می‌گیره و این اوکیه).
5. گام ۳: اجرا و دیباگ پیشرفته: کد رو از طریق HTML (پیشنهادی) یا GTM روی سایت می‌ذاریم. بعد با URL Inspection سرچ کنسول چک می‌کنیم که اسکیما در DOM رندر شده توسط گوگل قابل مشاهده باشه.
6. گام ۴: نظارت (Monitoring): در گزارش‌های Enhancements سرچ کنسول، حواسمون به خطاهای مربوط به بخش «استاندارد» اسکیمامون هست.

یادت باشه، اسکیما (و مخصوصاً اسکیمای سفارشی) یه بازی بلندمدته. هدف نهایی تو فقط گرفتن چند تا ستاره‌ی قشنگ در نتایج جستجو نیست.

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

جمع‌بندی

بهت تبریک می‌گم! تو الان یکی از پیشرفته‌ترین مباحث سئوی فنی رو یاد گرفتی. ما با هم فهمیدیم که «اسکیمای سفارشی» یه ابزار لوکس نیست، بلکه یه ضرورت برای اثبات «تخصص» (Expertise) و «مرجعیت» (Authoritativeness) در دنیای E-A-T محوره.

یاد گرفتیم که هدف ما از اسکیمای سفارشی، گرفتن ریچ ریزالت‌های رنگارنگ نیست؛ هدف ما صحبت مستقیم با «گراف دانش» گوگله.

فراموش نکن، این یه چرخه‌ی دائمیه:

1. توسعه بده (Extend): انواع استاندارد مثل Product رو بردار.
2. سفارشی‌سازی کن: ویژگی‌های تخصصی خودت رو بهش اضافه کن.
3. اعتبارسنجی کن (Validate): با Schema Markup Validator مطمئن شو گرامرت درسته.
4. دیباگ کن (Debug): با Rich Results Test مطمئن شو بخش استاندارد کارت درسته.
5. نظارت کن (Monitor): در سرچ کنسول مراقب خطاها باش.

از امروز، تو دیگه یه تولیدکننده محتوای معمولی نیستی. تو یه معماری هستی که داری به گوگل کمک می‌کنی وب رو عمیق‌تر و هوشمندانه‌تر درک کنه. برو و متخصص بودنت رو به گوگل ثابت کن!

سوالات متداول (FAQ)

۱. آیا اگر اسکیمای سفارشی من در Rich Results Test شکست بخورد، یعنی اشتباه کرده‌ام؟

نه، مطلقاً! این رایج‌ترین سوءتفاهمه. ابزار Rich Results Test فقط به تو می‌گه که آیا گوگل برای اون اسکیما، «نتیجه‌ی بصری غنی» (مثل ستاره یا قیمت) داره یا نه. از اونجایی که تو یه ویژگی سفارشی (مثلاً keyboardTravelDistance) ساختی، طبیعیه که گوگل ریچ ریزالتی براش نداشته باشه. تا زمانی که اسکیمای تو در ابزار Schema Markup Validator معتبر (Valid) باشه، کارت رو درست انجام دادی و گوگل اون اطلاعات رو برای گراف دانش خودش استفاده می‌کنه.

۲. بهتر است یک نوع (@type) کاملاً جدید اختراع کنم یا انواع موجود را توسعه دهم؟

در ۹۹ درصد موارد، تو باید انواع موجود رو توسعه (Extend) بدی. این بهترین شیوه‌ است. به جای اختراع یه نوع جدید مثل MyLaptopReview، از نوع استاندارد Article یا Product استفاده کن و بعد، ویژگی‌های سفارشی خودت رو به اون «اضافه» کن. اینطوری هم از مزایای اسکیمای استاندارد (مثل شانس ریچ ریزالت) بهره می‌بری و هم اطلاعات تخصصی خودت رو به گوگل می‌دی.

۳. برای اسکیمای سفارشی، از JSON-LD استفاده کنم یا Microdata؟

بدون شک JSON-LD. وقتی داری کدهای پیچیده و سفارشی می‌نویسی، آخرین چیزی که می‌خوای، قاطی شدن کدهای اسکیما با کدهای HTML صفحه‌ است. JSON-LD مثل یه بلوک کد تمیز و جدا در <head> یا <body> قرار می‌گیره، که «اعتبارسنجی» و «دیباگ» کردنش رو هزار برابر راحت‌تر از Microdata می‌کنه.