اسکیما چیست؟ راهنمای Schema و JSON-LD برای سئو
از انتخاب نوع Schema تا ساخت و بررسی JSON-LD؛ راهنمای عملی استفاده از داده ساختاریافته برای مقاله، محصول و کسبوکار.

اسکیما چیست؟ راهنمای Schema و JSON-LD برای سئو
از انتخاب نوع Schema تا ساخت و بررسی JSON-LD؛ راهنمای عملی استفاده از داده ساختاریافته برای مقاله، محصول و کسبوکار.
فهرست مطالب
- داده ساختاریافته چیست؟
- Schema و JSON-LD چه تفاوتی دارند؟
- داده ساختاریافته چه فایدهای دارد و چه چیزی را تضمین نمیکند؟
- برای هر صفحه کدام نوع Schema مناسب است؟
- چطور با ابزار Schema هیس JSON-LD بسازیم؟
- نمونه اول: توصیف یک سازمان با JSON-LD
- نمونه دوم: اطلاعات پایه یک مقاله
- چطور داده ساختاریافته را اعتبارسنجی کنیم؟
- محدودیت FAQ و پرسشوپاسخ در گوگل
- اشتباههای رایج هنگام ساخت Schema
- انتخاب نوع بر اساس ظاهر نتیجه
- افزودن اطلاعات پنهان یا حدسی
- نادیده گرفتن کدهای تکراری
- فرض نصب خودکار کد
- اعتماد کامل به چراغ سبز ابزار
- انتظار افزایش رتبه یا نمایش تضمینی
- پرسشهای متداول
- آیا Schema و JSON-LD یکی هستند؟
- آیا استفاده از Schema رتبه سایت را بالا میبرد؟
- آیا ابزار هیس کد را روی سایت نصب میکند؟
- اگر آزمون نتایج غنی خطایی نشان نداد، کار تمام است؟
- آیا افزودن FAQ باعث نمایش پرسشها در نتایج گوگل میشود؟
- جمعبندی
وقتی کاربری صفحه یک محصول، مقاله یا کسبوکار را میبیند، از متن و تصویر آن موضوع را تشخیص میدهد. موتور جستوجو هم صفحه را میخواند، اما برای فهم روشنتر رابطه میان نام، نویسنده، قیمت، سازمان یا مسیر صفحه میتوان از داده ساختاریافته کمک گرفت. این نشانهگذاری، محتوای تازهای به صفحه اضافه نمیکند؛ اطلاعاتی را که از قبل در صفحه دیده میشود، در قالبی منظمتر توصیف میکند.
در این راهنما تفاوت واژگان Schema و JSON-LD را روشن میکنیم، برای صفحههای رایج نوع مناسب را میسنجیم، یک نمونه کد میبینیم و مرحلهبهمرحله با ابزار Schema هیس خروجی میسازیم. در پایان هم میدانیم کد را چطور از نظر فنی و معنایی بررسی کنیم و چرا معتبر بودن آن بهتنهایی نمایش ویژه در گوگل را تضمین نمیکند.
داده ساختاریافته چیست؟
داده ساختاریافته راهی استاندارد برای توصیف اطلاعات یک صفحه است تا نرمافزارها بتوانند اجزای آن را با معنا و رابطه مشخصتری بخوانند. برای نمونه، در یک صفحه محصول میتوان نام کالا، تصویر، برند و قیمت را مشخص کرد؛ در صفحه مقاله میتوان عنوان، نویسنده و زمان انتشار را توصیف کرد. اطلاعات نشانهگذاریشده باید با چیزی که بازدیدکننده در همان صفحه میبیند هماهنگ باشد.
این استاندارد واژگان مشترکی مانند Organization، Product، Article و BreadcrumbList را تعریف میکند. هر نوع، ویژگیهایی دارد که کمک میکنند یک موجودیت یا رابطه را دقیقتر بیان کنیم. همه ویژگیهای این استاندارد الزاماً برای نمایش جستوجوی گوگل کاربرد ندارند؛ گوگل فقط از مجموعهای از نوعها و قواعد ویژه خود برای قابلیتهای مشخص پشتیبانی میکند.
Schema و JSON-LD چه تفاوتی دارند؟
این دو مکمل یکدیگرند، اما یکی نیستند. این استاندارد واژگان و معنا را فراهم میکند؛ JSON-LD قالبی مبتنی بر JSON است که میتوان با آن همان واژگان را در صفحه نوشت. در یک بیان ساده، این واژگان پاسخ میدهند «چه چیزی را توصیف میکنیم؟» و JSON-LD میگوید «این توصیف را در چه قالبی مینویسیم؟»
گوگل JSON-LD را قالب پیشنهادی خود معرفی میکند؛ Microdata و RDFa نیز قالبهای پشتیبانیشدهاند. JSON-LD معمولاً به شکل یک بلوک مستقل در صفحه قرار میگیرد، بنابراین مدیریت آن میتواند از نشانهگذاری پراکنده میان اجزای HTML سادهتر باشد. انتخاب قالب باید با سامانه سایت و توان تیم برای نگهداری کد هم سازگار باشد. راهنمای رسمی گوگل درباره قواعد داده ساختاریافته فرمتهای پذیرفتهشده و دستورالعملهای عمومی را شرح میدهد.
داده ساختاریافته چه فایدهای دارد و چه چیزی را تضمین نمیکند؟
نشانهگذاری درست میتواند به موتور جستوجو کمک کند اجزای صفحه را بهتر تفسیر کند و ممکن است صفحه را برای بعضی قابلیتهای جستوجو واجد شرایط سازد. این کار میانبر رتبهگیری نیست و باعث نمیشود گوگل الزاماً نتیجهای متفاوت نمایش دهد. واجدشرایط شدن نیز با انتخاب نهایی گوگل یکی نیست؛ الگوریتم میتواند با توجه به صفحه، جستوجو و تجربه کاربر تصمیم دیگری بگیرد.
مهمتر از همه، داده باید دقیق، بهروز و نماینده محتوای اصلی صفحه باشد. اطلاعات پنهان، ساختگی، نامرتبط یا قدیمی ممکن است با دستورالعملهای گوگل ناسازگار باشد. آزمون فنی هم نمیتواند همه خطاهای معنایی را تشخیص دهد؛ بررسی انسانی لازم است.
برای هر صفحه کدام نوع Schema مناسب است؟
نوع را از روی هدف و محتوای واقعی صفحه انتخاب کنید. یک سایت میتواند در صفحههای مختلف از نوعهای متفاوت استفاده کند؛ لازم نیست یک نوع را برای همه صفحهها به کار ببرد.

نوع | چه زمانی بررسیاش کنیم؟ | نکته مهم |
|---|---|---|
Organization | برای معرفی سازمان یا برند و اطلاعات رسمی آن | نام، نشانی و لوگو باید به همان سازمان تعلق داشته باشند. |
LocalBusiness | برای کسبوکاری با مکان یا خدمت محلی مشخص | نشانی و جزئیات تماس را دقیق و واقعی وارد کنید. |
Product | برای صفحهای که بر یک محصول مشخص متمرکز است | قیمت، موجودی و پیشنهاد باید با وضعیت قابلمشاهده صفحه هماهنگ باشند. |
Article یا BlogPosting | برای مقاله، خبر یا نوشته وبلاگی | عنوان، تصویر، نویسنده و تاریخها را با محتوای صفحه تطبیق دهید. |
BreadcrumbList | برای نمایش جایگاه صفحه در سلسلهمراتب سایت | مسیر باید با ساختار واقعی سایت همخوان باشد. |
FAQPage | وقتی پرسشوپاسخهای تحریریه در صفحه دیده میشوند | برای بیشتر سایتها نباید انتظار نتیجه غنی پرسشوپاسخ در گوگل داشت. |
یک صفحه ممکن است چند موجودیت مرتبط داشته باشد، اما هر کدام باید معنای جدا و واقعی داشته باشند. اگر افزونه، قالب سایت و کد دستی همزمان یک سازمان یا مقاله را معرفی میکنند، خروجی نهایی را بررسی کنید تا دادههای تکراری یا متناقض باقی نمانند.
چطور با ابزار Schema هیس JSON-LD بسازیم؟
سازنده Schema و JSON-LD هیس برای چند نوع متداول، فرم ساخت خروجی دارد. ساخت کد پایان کار نیست؛ ابتدا اطلاعات را بررسی کنید و بعد آن را با روش مناسب در صفحه سایت قرار دهید.
صفحه را دستهبندی کنید. روشن کنید صفحه درباره سازمان، محصول، مقاله یا موضوع دیگری است. اگر موضوع اصلی صفحه یک مقاله است، صرفاً برای گرفتن نمایش خاص، نوع محصول انتخاب نکنید.
نوع را در ابزار برگزینید. گزینهای را انتخاب کنید که تعریفش با محتوای صفحه جور باشد. عنوان گزینه بهتنهایی دلیل کافی نیست؛ ماهیت صفحه معیار است.
فیلدها را با اطلاعات واقعی پر کنید. نام رسمی، نشانی عمومی سایت و لوگو را از منابع معتبر خودتان بردارید. ایمیل، تلفن، قیمت یا امتیازی را که در صفحه وجود ندارد حدس نزنید.
قالب خروجی را انتخاب کنید. حالت خوانا بازبینی را آسان میکند؛ JSON فشرده همان داده را کوتاهتر مینویسد و خروجی HTML آماده در تگ اسکریپت قرار میگیرد.
خروجی را بخوانید. نوع، مقادیر، نشانیها و نشانهگذاری JSON را بازبینی کنید. سپس کد را با روش مورد تأیید سامانه مدیریت محتوای خود در صفحه درست قرار دهید.
پس از نصب، آزمایش کنید. ابزار آزمون نتایج غنی گوگل برای بررسی نوعهای پشتیبانیشده گوگل مناسب است؛ اعتبارسنج واژگان عمومی را بررسی میکند. این دو ابزار هدف یکسانی ندارند.
خود ابزار هیس کد را تولید میکند؛ این کار بهمعنای نصب خودکار یا انتشار آن روی سایت نیست. اگر درباره محل درج یا اثر کدهای موجود مطمئن نیستید، پیش از تغییر از توسعهدهنده یا پشتیبانی CMS راهنمایی بگیرید.
نمونه اول: توصیف یک سازمان با JSON-LD
این نمونه صرفاً الگوی آموزشی است. مقادیر نمونه را با دادههای واقعی همان کسبوکار جایگزین کنید و تنها ویژگیهایی را نگه دارید که درباره سازمان درستاند.
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "نام رسمی سازمان",
"url": "https://example.com/",
"logo": "https://example.com/images/logo.png"
}@context واژگان مورد استفاده را مشخص میکند و @type نوع موجودیت را میگوید. نشانی لوگو باید به فایل تصویری عمومی و در دسترس اشاره کند؛ نشانی نمونه بالا واقعی نیست و باید جایگزین شود.
نمونه دوم: اطلاعات پایه یک مقاله
در نمونه زیر نام نویسنده، عنوان، تاریخها و تصویر همگی مقدار نمونهاند. در یک سایت واقعی، آنها را با اطلاعات آشکار و دقیق صفحه جایگزین کنید. تاریخ انتشار و ویرایش را با زمان واقعی ثبت کنید.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "عنوان واقعی مقاله",
"image": [
"https://example.com/images/article-cover.jpg"
],
"datePublished": "2026-01-15T09:00:00+03:30",
"dateModified": "2026-01-18T11:30:00+03:30",
"author": {
"@type": "Person",
"name": "نام نویسنده"
}
}این مثال، شکل پایه توصیف یک مقاله را نشان میدهد و بهتنهایی تضمین نمیکند که گوگل نتیجه غنی نشان دهد. از تاریخ ساختگی یا تصویر نامرتبط استفاده نکنید. اگر نویسنده یک سازمان است، نوع و اطلاعات نویسنده را با هویت واقعی او هماهنگ کنید. جزئیات نوعهای Article، NewsArticle و BlogPosting در راهنمای رسمی گوگل آمده است.
چطور داده ساختاریافته را اعتبارسنجی کنیم؟
اعتبارسنجی را در دو سطح انجام دهید: آیا کد از نظر ساختاری خوانده میشود و آیا معنای آن با صفحه یکی است؟ پیش از انتشار، این موارد را مرور کنید:
نوع Schema با موضوع و هدف صفحه هماهنگ است.
مقادیر بهروز و با متن و تصویر قابلمشاهده سازگارند.
JSON از نظر ویرگول، دونقطه، آکولاد، کروشه و کوتیشن دوتایی درست است.
نشانیهای URL با پروتکل درست نوشته شدهاند و مقصدشان باز میشود.
ویژگیهای لازم برای قابلیت مشخص گوگل، طبق مستندات همان قابلیت درج شدهاند.
کد در همان صفحهای قرار گرفته که آن را توصیف میکند و دسترسی خزنده به آن مسدود نیست.
پس از استقرار، بازرسی URL و گزارشهای مرتبط Search Console نیز بررسی میشوند.
آزمون نتایج غنی گوگل فقط قابلیتهای پشتیبانیشده گوگل را میسنجد، نه تمام واژگان این استاندارد را. در سوی دیگر، اعتبارسنج رسمی میتواند خطاهای مربوط به واژگان را نشان دهد اما تصمیم گوگل درباره نمایش را پیشبینی نمیکند. نبود خطا در ابزار، بررسی معنایی و تطبیق با راهنمای نوع انتخابی را بینیاز نمیکند.

برای ارزیابی زمینه فنی گستردهتر صفحه، از جمله خزش، canonical و ریدایرکت، میتوانید راهنمای ممیزی فنی سئو در هیس را هم ببینید.
محدودیت FAQ و پرسشوپاسخ در گوگل
نوع FAQPage در این استاندارد تعریف شده است؛ اما تعریف آن به معنای نمایش ویژه در Google Search نیست. Google Search Central اعلام کرده نمایش غنی FAQ از ۷ مه ۲۰۲۶ دیگر در نتایج جستوجوی گوگل نشان داده نمیشود. بنابراین، برای گرفتن این نمایش یا افزایش بازدید، FAQ markup اضافه نکنید. اگر به دلایل فنی دیگری آن را به کار میبرید، فقط پرسشها و پاسخهای واقعی و قابلمشاهده صفحه را توصیف کنید. بهروزرسانیهای رسمی Google Search Central توقف این قابلیت را ثبت کرده است.
پرسشها و پاسخها را برای کمک به خواننده بنویسید و فقط زمانی نشانهگذاری کنید که همان متن در صفحه دیده شود. اگر کاربران پاسخهای متعددی برای یک پرسش ارسال میکنند، پیش از انتخاب نوع داده تفاوت FAQ تحریریه با صفحه پرسشوپاسخ کاربرمحور را در مستندات مربوط بررسی کنید.
اشتباههای رایج هنگام ساخت Schema
انتخاب نوع بر اساس ظاهر نتیجه
یک نوع را به این دلیل که احتمال میدهید نتیجه جستوجو چشمگیرتری بسازد انتخاب نکنید. نوع باید محتوای واقعی صفحه را توصیف کند؛ انتخاب نادرست میتواند کد را از معنای صفحه دور کند.
افزودن اطلاعات پنهان یا حدسی
قیمت، تخفیف، امتیاز، موجودی یا ویژگی سازمان را تنها وقتی درج کنید که واقعیت داشته باشد و با محتوا هماهنگ باشد. داده ساختگی یا قدیمی برای کاربر و موتور جستوجو گمراهکننده است.
نادیده گرفتن کدهای تکراری
قالب سایت یا افزونه ممکن است خودش Schema تولید کند. پیش از افزودن کد دستی، صفحه را بررسی کنید. چند نسخه متناقض از یک موجودیت میتواند تفسیر صفحه را دشوار کند.
فرض نصب خودکار کد
گرفتن خروجی از ابزار به این معنا نیست که کد روی سایت قرار گرفته است. کد را در سامانه سایت و صفحه مناسب نصب کنید و پس از آن نسخه اجراشده را بررسی کنید.
اعتماد کامل به چراغ سبز ابزار
ابزارهای خودکار نشانهگذاری و بعضی خطاهای فنی را پیدا میکنند، اما نمیدانند اطلاعات واقعاً درست است یا با قصد صفحه تناسب دارد. مسئولیت بررسی معنایی با صاحب سایت است.
انتظار افزایش رتبه یا نمایش تضمینی
داده ساختاریافته به فهم محتوا کمک میکند و میتواند شرط برخی قابلیتها باشد؛ اما وعدهای برای رتبه بالاتر یا نمایش قطعی نیست. کیفیت صفحه و سود آن برای مخاطب را در اولویت بگذارید.
پرسشهای متداول
آیا Schema و JSON-LD یکی هستند؟
خیر. این استاندارد نوعها و واژگان توصیف را تعریف میکند؛ JSON-LD یکی از قالبهای نوشتن آن دادههاست.
آیا استفاده از Schema رتبه سایت را بالا میبرد؟
نباید از آن انتظار افزایش مستقیم و قطعی رتبه داشت. داده ساختاریافته میتواند به فهم محتوای صفحه کمک کند و آن را برای بعضی قابلیتهای جستوجو واجد شرایط سازد، اما نتیجه نهایی به انتخاب گوگل بستگی دارد.
آیا ابزار هیس کد را روی سایت نصب میکند؟
خیر. ابزار هیس خروجی را میسازد. باید آن را با روش مناسب در صفحه موردنظر قرار دهید و سپس بررسی کنید که نسخه اجراشده درست باشد.
اگر آزمون نتایج غنی خطایی نشان نداد، کار تمام است؟
خیر. آزمون، خطاهای قابلشناسایی در قالبهای پشتیبانیشده را بررسی میکند. درستی اطلاعات، ارتباط آنها با صفحه و رعایت قواعد کیفی را نیز جداگانه بسنجید.
آیا افزودن FAQ باعث نمایش پرسشها در نتایج گوگل میشود؟
خیر. Google Search نمایش غنی FAQ را از ۷ مه ۲۰۲۶ متوقف کرده است. پرسشها را برای خواننده بنویسید و از این نوع داده برای انتظار نمایش بازشونده استفاده نکنید.
جمعبندی
داده ساختاریافته توضیح منظمتری از محتوای صفحه در اختیار نرمافزارها میگذارد. این استاندارد واژگان توصیف را فراهم میکند و JSON-LD راهی رایج برای نوشتن آن است. انتخاب نوع درست، استفاده از داده واقعی، قرار دادن کد در صفحه مرتبط و بررسی فنی و معنایی، از خود تولید کد مهمترند. ابزار اسکیما هیس ساخت خروجی را آسان میکند؛ نتیجه را پیش از نصب بازبینی کنید و نمایش ویژه در گوگل را قطعی فرض نکنید.
برای رشد کسبوکارتان آمادهاید؟
با هیس دیجیتال، مسیر مناسب رشد و بازاریابی کسبوکار خود را پیدا کنید.
