Schema Markup یا اسکیما مارکاپ یعنی به صفحه های سایتت یک لایه اطلاعات ساختاریافته اضافه کنی تا موتورهای جستجو بهتر بفهمن صفحه درباره چیه، چه اجزایی داره و هر بخش چه معنایی میده. این کار قرار نیست محتوای بد رو نجات بده یا یک شبه رتبه بسازه؛ اما می تونه فهم گوگل از صفحه رو دقیق تر کنه و در بعضی موارد، شانس نمایش Rich Result مثل FAQ، Product، Review، Breadcrumb، Article یا Organization رو بالا ببره. هشت پا این راهنما رو برای سئوکارها، تیم های محتوا و مدیر سایت هایی نوشته که می خوان بفهمن Structured Data دقیقاً چیست، کدام اسکیماها ارزش اجرا دارن، چطور باید اضافه شون کرد و چطور خطاهاشون رو تست کرد. خلاصه اش اینه: اسکیما وقتی ارزش داره که دقیق، مرتبط با محتوای قابل مشاهده صفحه و مطابق دستورالعمل گوگل باشه؛ نه اینکه هر چیزی رو توی JSON-LD بریزیم و بگیم خب دیگه گوگل خودش می فهمه.

Schema Markup چیست؟

Schema Markup کدی است که اطلاعات صفحه را به صورت ساختاریافته برای موتورهای جستجو توضیح می دهد. این کد معمولاً با استاندارد Schema.org و فرمت JSON-LD نوشته می شود و کمک می کند گوگل بفهمد صفحه درباره مقاله، محصول، سازمان، سوالات متداول، مسیر Breadcrumb، ویدئو، رویداد یا نوع دیگری از محتواست. مثلاً توی متن عادی صفحه ممکنه نوشته باشی هشت پا خدمات مدیریت گوگل ادز ارائه می‌دهد. آدم می فهمه با یک برند و سرویس طرفه، اما موتور جستجو باید این اطلاعات رو از HTML، متن، لینک ها و سیگنال های مختلف استخراج کنه. با Structured Data می تونی دقیق تر بگی این صفحه درباره یک Organization، Service، Article یا Breadcrumb است. گوگل در مستندات Structured Data توضیح میده که از داده ساختاریافته برای فهم محتوای صفحه و جمع آوری اطلاعات درباره وب و چیزهایی مثل افراد، کتاب ها یا شرکت ها استفاده می کنه. همین منبع میگه گوگل می تونه از structured data برای نمایش richer result در سرچ استفاده کنه، اما این نمایش همیشه تضمینی نیست. نکته: اسکیما به گوگل نمیگه به من رتبه بده. اسکیما میگه این اطلاعات صفحه منظم و قابل‌فهم‌تر است. فرق این دوتا مهمه، چون خیلی ها از همین جا توقع اشتباه می سازن.

Structured Data با Schema Markup چه فرقی دارد؟

Structured Data مفهوم کلی داده‌های ساختاریافته است و Schema Markup روش پیاده‌سازی این داده‌ها در صفحه وب محسوب می‌شود.

اصطلاح	معنی	نمونه
Structured Data	اطلاعات دارای ساختار مشخص	قیمت، امتیاز و نویسنده
Schema.org	واژگان استاندارد انواع داده	Article و Product
Schema Markup	کد قرارگرفته در صفحه	JSON-LD
Rich Result	نمایش پیشرفته در نتایج	Breadcrumb و اطلاعات محصول

اسکیما تکنیکی موقت نیست؛ استانداردی جاافتاده برای انتقال معنی محتوا به موتورهای جستجو است.

نکته: در حرف های روزمره سئو، معمولاً وقتی می گیم، اسکیما منظورمان همان Structured Data با واژگان Schema.org است. پس اگر کسی گفت Structured Data اضافه، کن معمولاً یعنی برو Schema Markup درست پیاده کن.

اسکیما چه کمکی به سئو می کند؟

برای اینکه داده‌های ساختاریافته با محتوای صفحه هماهنگ بمانند، اصول سئو محتوا را در عنوان‌ها، توضیحات و ساختار پاسخ‌ها رعایت کنید.

اسکیما به گوگل کمک می کند محتوای صفحه را دقیق تر بفهمد و در بعضی موارد، صفحه را برای Rich Result های مشخص واجد شرایط کند. اما Schema Markup به تنهایی تضمین رتبه بهتر یا نمایش Rich Result . نیست صفحه باید محتوای درست، دسترسی پذیر، مرتبط و مطابق دستورالعمل های گوگل داشته باشد. سه فایده اصلی اسکیما:

• فهم بهتر صفحه توسط موتور جستجو: مثلاً وقتی برای مقاله از Article Schema استفاده می کنی، به گوگل میگی عنوان، نویسنده، تاریخ انتشار، تصویر و نوع محتوا چیست. این کار جای متن خوب را نمی گیرد، اما اطلاعات کلیدی را مرتب تر می کند.
• امکان نمایش Rich Result: Product Schema ممکنه اطلاعاتی مثل قیمت، موجودی و امتیاز را برای نمایش های غنی تر آماده کند. Breadcrumb Schema هم می تونه مسیر صفحه را در نتایج واضح تر نشان بدهد.
• کمک به نظم تکنیکال سایت: وقتی برای صفحات اصلی سایت Organization، WebSite، Breadcrumb، Product یا Article درست تعریف می کنی، یک لایه معنایی منظم تر می سازی. این مخصوصاً برای سایت های بزرگ، فروشگاهی و محتوایی کمک می کند. گوگل صریحاً میگه استفاده از Structured Data فقط امکان حضور یک ویژگی را فعال می کند و تضمین نمی کند که آن ویژگی حتماً در نتایج نمایش داده شود. حتی اگر صفحه در Rich Results Test درست باشد، ممکنه الگوریتم گوگل بسته به عوامل مختلف تصمیم بگیرد یک نتیجه ساده تر برای مخاطب بهتر است.

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

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

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

Schema Markup معمولاً به عنوان فاکتور مستقیم رتبه بندی معرفی نمی شود، اما می تواند به صورت غیرمستقیم روی عملکرد ارگانیک اثر بگذارد. وقتی صفحه برای Rich Result واجد شرایط شود، ممکن است ظاهر نتیجه در SERP بهتر شود، CTR تغییر کند یا گوگل محتوای صفحه را واضح تر درک کند. اما اینجا باید خیلی شفاف باشیم. اگر محتوای صفحه ضعیف است، Search Intent را جواب نمی دهد، Title بدی دارد یا صفحه از نظر فنی مشکل دارد، اضافه کردن چند خط JSON-LD معجزه نمی کند. اسکیما روی صفحه خوب، مثل برچسب گذاری دقیق قفسه های یک فروشگاه مرتب عمل می کند. روی صفحه بد، فقط برچسب قشنگ روی جنس بی کیفیت می چسباند. Google Search Central در بخش Structured Data چند Case Study منتشر کرده؛ مثلاً در مستندات خودش اشاره می کند Rakuten در صفحات دارای structured data، زمان حضور ۱.۵ برابر بیشتری نسبت به صفحات بدون structured data دیده و Nestlé برای صفحاتی که rich result نشان داده اند، CTR بالاتری نسبت به نتایج غیر rich گزارش کرده است. این ها نمونه های موردی اند، نه تضمین عمومی برای همه سایت ها. نمونه فرضی: اگر یک فروشگاه صفحه محصول کاملی دارد، قیمت و موجودی واقعی را نشان می دهد، تصویر مناسب دارد و Product Schema هم درست پیاده شده، احتمالاً شانس بهتری برای نمایش اطلاعات محصول در نتایج دارد. اما اگر همان فروشگاه قیمت را در صفحه نشان نمی دهد و فقط در Schema قیمت ساختگی گذاشته، هم خطر خطای Structured Data دارد، هم اعتماد کاربر را خراب می کند.

گوگل چه فرمت هایی را برای Structured Data پشتیبانی می کند؟

گوگل سه فرمت JSON-LD، Microdata و RDFa را پشتیبانی می‌کند. JSON-LD معمولاً انتخاب مناسب‌تری است، چون از HTML صفحه جدا می‌ماند و نگهداری آن ساده‌تر است.

فرمت	محل استفاده	مزیت
JSON-LD	بلوک جداگانه در صفحه	پیاده‌سازی و نگهداری ساده
Microdata	داخل تگ‌های HTML	ارتباط مستقیم با عناصر صفحه
RDFa	داخل ویژگی‌های HTML	انعطاف‌پذیری بالا

JSON-LD چیست و چرا بیشتر پیشنهاد می شود؟

JSON-LD یک فرمت برای نوشتن داده ساختاریافته با ساختار JSON است. در سئو، معمولاً کد JSON-LD را داخل صفحه قرار می دهیم تا نوع محتوا، ویژگی ها و ارتباط بین اجزای صفحه را برای موتور جستجو توضیح دهد. نمونه ساده Article Schema :

> script type=”application/ld+json <” } @” context”: ” ,” @” type”: “Article ,” ” headline”: “Schema Markup ,” چیست؟ ” author :” } @” type”: “Organization ,” ” name :” “هشت پا” , { ” datePublished”: “2026-08-16 ,” ” dateModified”: “2026-08-16 ,” ” mainEntityOfPage :” } @” type”: “WebPage ,” @” id”: ” “/ { { /> script < این کد به تنهایی کافی نیست. باید عنوان صفحه واقعاً همین باشد، نویسنده یا ناشر در سایت مشخص باشد، تاریخ ها با واقعیت صفحه بخوانند و URL هم همان صفحه اصلی باشد. اگر Schema یک چیز بگه و خود صفحه چیز دیگر، گوگل ممکنه آن را نادیده بگیرد یا حتی خطا بگیرد. نکته: JSON-LD را کپی پیست کور نکن. هر فیلد باید از خود صفحه بیاد. اگر چیزی را در صفحه نداری، بی جهت در Schema اضافه نکن.

کدام نوع اسکیماها برای بیشتر سایت ها مهم اند؟

همه سایت ها به همه نوع Schema نیاز ندارند. انتخاب نوع اسکیما باید بر اساس نوع صفحه، هدف صفحه، محتوای قابل مشاهده و Rich Result های پشتیبانی شده توسط گوگل انجام شود. اسکیما زدن برای هرچیزی که اسمش در Schema.org هست، لزوماً برای سئو مفید نیست.

گوگل یک گالری از structured data feature های پشتیبانی شده در Search دارد؛ از Article و Breadcrumb تا Product، Organization، Local Business، Event، Job Posting، Recipe و موارد دیگر. خود گوگل میگه برای واجد شرایط شدن در rich result های مشخص، باید راهنمای همان feature را دنبال کنی. چند Schema کاربردی‌تر:

• Organization Schema : برای معرفی برند، لوگو، URL، پروفایل های اجتماعی و اطلاعات کلی سازمان. برای سایت های شرکتی و برندها معمولاً از پایه های اصلیه.
• WebSite Schema : برای معرفی سایت و در بعضی موارد قابلیت Sitelinks Search Box، اگر شرایطش وجود داشته باشد. این اسکیما معمولاً روی صفحه اصلی میاد.
• BreadcrumbList Schema : برای نشان دادن مسیر صفحه در ساختار سایت. برای فروشگاه ها، بلاگ ها و سایت های دسته بندی شده خیلی مهمه، چون مسیر صفحه را شفاف تر می کند.
• Article یا BlogPosting Schema : برای مقاله ها، خبرها و محتوای آموزشی. اینجا باید headline، image، author، datePublished و dateModified را درست مدیریت کنی.
• Product Schema : برای صفحه محصول. قیمت، موجودی، تصویر، نام، برند و در صورت وجود واقعی، امتیاز و نقدها باید با صفحه هماهنگ باشند.
• FAQPage Schema : برای سوالات متداولی که واقعاً در صفحه قابل مشاهده اند. البته باید دقت کنی برای همه صفحات لازم نیست و گوگل هم همیشه آن را نمایش نمی دهد.
• LocalBusiness Schema : برای کسب وکارهای محلی با آدرس، شماره تماس، ساعت کاری و اطلاعات واقعی. اگر چند شعبه داری، ساختار باید دقیق تر طراحی شود.

نکته: اگر سایت خدماتی داری، لازم نیست برای هر صفحه یک Product Schema بچسبونی چون فکر می کنی گوگل خوشش میاد. نوع اسکیما باید با ماهیت صفحه یکی باشد. صفحه خدمات با محصول فیزیکی فرق دارد؛ بله، حتی اگر هر دو پول درمیارن.

کدام اسکیماها برای سایت خدماتی مناسب ترند؟

برای سایت خدماتی، معمولاً Organization، WebSite، Breadcrumb، Article، FAQPage و در بعضی موارد Service یا LocalBusiness کاربرد بیشتری دارند. اما انتخاب نهایی به نوع صفحه بستگی دارد، نه فقط نوع کسب وکار. برای سایت خدماتی مثل آژانس دیجیتال مارکتینگ، این ترکیب منطقی تره:

• صفحه اصلی: Organization + WebSite
• صفحات خدمات: Breadcrumb + Service، اگر ساختار صفحه واقعاً خدمت را توضیح می دهد
• مقالات آموزشی: Article یا BlogPosting + Breadcrumb
• صفحات سوالات متداول: FAQPage، فقط اگر سوال و جواب ها در خود صفحه دیده می شوند
• صفحه تماس یا شعبه: LocalBusiness یا Organization با اطلاعات واقعی
• صفحات نمونه کار: بسته به ساختار، CreativeWork یا WebPage، اما با احتیاط نمونه فرضی: صفحه مدیریت گوگل ادز اگر شامل شرح خدمت، فرایند همکاری، مزایا، سوالات متداول و CTA درخواست مشاوره است، می تواند Breadcrumb، Service و FAQPage داشته باشد. اما اگر فقط یک مقاله آموزشی درباره گوگل ادز است، Article یا BlogPosting انتخاب بهتریه.

کدام اسکیماها برای فروشگاه اینترنتی مهم ترند؟

برای فروشگاه اینترنتی، Product Schema، Offer، AggregateRating، Review، BreadcrumbList و Organization معمولاً مهم ترند. البته شرط اصلی اینه که داده هایی مثل قیمت، موجودی، امتیاز و نقد واقعاً در صفحه وجود داشته باشند و با واقعیت محصول هماهنگ باشند.

برای فروشگاه، این ها خیلی مهم اند:

• Product : نام، تصویر، توضیح، برند یا شناسه محصول را مشخص می کند. اگر صفحه محصول داری، این پایه اصلیه.
• Offer : قیمت، ارز، موجودی و وضعیت فروش را مشخص می کند. قیمت داخل Schema باید با قیمت قابل مشاهده در صفحه یکی باشد.
• AggregateRating : میانگین امتیاز کاربران را نشان می دهد، اما فقط اگر امتیاز واقعی و قابل مشاهده در صفحه داری. امتیاز ساختگی؟ نه، لطفاً نه.
• Review : برای نقدهای واقعی کاربران یا متخصصان. اگر خودت برای خودت نقد ساختی، داری به سمت دردسر می ری.
• BreadcrumbList : مسیر دسته بندی محصول را روشن می کند؛ مثلاً خانه < کفش < کفش مردانه < محصول.
• MerchantReturnPolicy و ShippingDetails : در بعضی بازارها و ساختارهای فروشگاهی می تونن برای اطلاعات ارسال و مرجوعی مهم باشند، اما باید طبق مستندات و داده واقعی پیاده شوند. نمونه فرضی: اگر محصولی ناموجوده اما Schema هنوز InStock نشان می دهد، این خطای ساده می تونه تجربه کاربر و کیفیت داده را خراب کند. کاربر وارد صفحه میشه، محصول موجود نیست، ولی گوگل از Structured Data چیز دیگری فهمیده. این دقیقاً همان ناهماهنگی ایه که نباید داشته باشی.

آموزش افزودن Schema Markup به سایت

برای افزودن اسکیما، اول باید نوع صفحه و هدف آن را مشخص کنی، بعد نوع Schema مناسب را انتخاب کنی، کد JSON-LD را بسازی، داخل صفحه قرار بدی، با ابزارهای معتبر تست کنی و بعد از ایندکس، در Search Console وضعیتش را بررسی کنی. مراحل عملی:

1. نوع صفحه را مشخص کن مقاله است؟ محصول است؟ صفحه خدمات است؟ صفحه سازمان است؟ صفحه FAQ است؟ تا این روشن نباشه، انتخاب Schema هم شانسی میشه.
2. Rich Result هدف را بررسی کن ببین گوگل برای این نوع محتوا چه structured data هایی را پشتیبانی می کند. هر چیزی که در Schema.org هست، الزاماً Rich Result گوگل ندارد.
3. داده های قابل مشاهده صفحه را استخراج کن عنوان، نویسنده، تاریخ، تصویر، قیمت، موجودی، سوالات، مسیر Breadcrumb و اطلاعات برند باید واقعاً در صفحه باشند.
4. کد JSON-LD را بساز کد را تمیز، بدون فیلدهای الکی و مطابق مستندات بنویس.
5. کد را در صفحه قرار بده معمولاً داخل head یا body صفحه قابل پیاده سازی است. مهم اینه که Googlebot بتواند آن را ببیند.
6. با Rich Results Test تست کن خطاها، هشدارها و eligibility را بررسی کن.
7. با URL Inspection بررسی کن بعد از انتشار، ببین گوگل صفحه را چطور می بیند.
8. Search Console را پایش کن اگر structured data report برای آن feature وجود دارد، خطاها و هشدارها را دوره ای چک کن. گوگل Rich Results Test را ابزاری برای تست صفحات عمومی معرفی می کند تا ببینی چه rich result هایی می توانند از structured data صفحه ساخته شوند. اما همین جا یادت باشد: پاس شدن تست یعنی کد از نظر ابزار قابل قبول است، نه اینکه حتماً در SERP نمایش می گیری.

نمونه کد Schema برای مقاله

برای مقاله‌های بلاگ معمولاً از Article یا BlogPosting استفاده می‌شود. نمونه ساده:

{
 "@type": "BlogPosting",
 "headline": "آموزش Schema Markup",
 "author": {"@type": "Organization", "name": "هشت پا"},
 "datePublished": "2026-08-16"
}

عنوان، نویسنده و تاریخ باید با اطلاعات قابل مشاهده صفحه هماهنگ باشند.

نمونه کد FAQ Schema

FAQPage برای پرسش‌وپاسخ‌هایی مناسب است که واقعاً در صفحه نمایش داده می‌شوند. نمونه ساده:

{
 "@type": "FAQPage",
 "mainEntity": [{
 "@type": "Question",
 "name": "Schema Markup چیست؟",
 "acceptedAnswer": {"@type": "Answer", "text": "روشی برای ارائه داده ساختاریافته است."}
 }]
}

سؤال و پاسخ پنهان یا نامرتبط وارد اسکیما نکنید.

نمونه کد Product Schema

Product Schema فقط برای صفحه یک محصول مشخص مناسب است. نمونه ساده:

{
 "@type": "Product",
 "name": "نام محصول",
 "offers": {
 "@type": "Offer",
 "priceCurrency": "IRR",
 "price": "3200000",
 "availability": "InStock"
 }
}

قیمت و موجودی داخل اسکیما باید همیشه با اطلاعات قابل مشاهده محصول یکسان باشند.

چطور Structured Data را تست کنیم؟

برای تست Structured Data باید از ترکیب Rich Results Test، Schema Markup Validator و URL Inspection استفاده کنی. Rich Results Test بیشتر برای بررسی eligibility نسبت به rich result های گوگل کاربرد دارد، اما Schema Markup Validator برای بررسی عمومی تر Schema.org مناسب تر است. گوگل خودش میگه برای generic schema validation از Schema Markup Validator استفاده کن و برای دیدن اینکه کدام rich result های گوگل می تونن از داده صفحه ساخته شوند، Rich Results Test ابزار رسمی گوگله. روش تست:

1. اول کد را قبل از انتشار تست کن اگر کد JSON-LD از نظر syntax مشکل دارد، همان اول معلوم می شود. مثلاً یک ویرگول اضافه می تواند کل JSON را خراب کند.
2. بعد URL منتشرشده را تست کن چون گاهی کدی که در محیط تست درست است، روی صفحه واقعی با قالب، کش یا JS درست لود نمی شود.
3. خطاها را از هشدارها جدا کن Error معمولاً مانع eligibility می شود؛ Warning الزاماً مانع نیست، اما بهتره بررسی شود.
4. URL Inspection را ببین گاهی ابزار تست کد را می بیند، اما Googlebot در نسخه Crawl شده چیز متفاوتی دیده.
5. Search Console را دوره ای چک کن اگر structured data report فعال شده، خطاهای دسته ای را از آنجا دنبال کن. نکته: تست ابزار یعنی شروع بررسی، نه پایانش. اگر Rich Results Test گفت Valid، هنوز باید ببینی داده ها با محتوای قابل مشاهده صفحه هماهنگ اند یا نه.

خطا و هشدار در Structured Data چه فرقی دارد؟

Error یعنی یک مشکل جدی وجود دارد که معمولاً جلوی واجد شرایط شدن صفحه برای Rich Result مربوطه را می گیرد. Warning یعنی داده ای توصیه شده ناقص است، اما ممکنه همچنان صفحه از نظر فنی eligible باشد.

: مثال

• Error : در Product Schema، فیلد ضروری name یا offers وجود ندارد. این یعنی گوگل نمی تواند آن ساختار را کامل بفهمد.
• Warning : تصویر، برند یا یک ویژگی توصیه شده ناقص است. شاید صفحه همچنان قابل قبول باشد، اما نتیجه برای کاربر کامل تر نیست.
• خطای محتوایی: Review داخل Schema هست، اما در صفحه به کاربر نمایش داده نشده. این حتی اگر ابزار بعضی بخش ها را رد نکند، از نظر guideline خطرناک است. گوگل در guidelines میگه بعضی quality guideline ها با ابزار خودکار به راحتی قابل تست نیستند و نقض آن ها می تواند باعث شود structured data درست از نظر syntax هم برای Rich Result نمایش داده نشود یا حتی به عنوان spam علامت بخورد. نکته: فقط دنبال سبز شدن ابزار نباش. بعضی خطاهای خطرناک، فنی نیستند؛ اخلاقی و محتوایی اند. مثل امتیاز جعلی، قیمت اشتباه یا اطلاعات پنهان.

مهم ترین قوانین گوگل برای Structured Data

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

قوانین گوگل برای Structured Data یک هدف ساده دارند: داده ای که در Schema می گذاری باید واقعی، مرتبط، قابل مشاهده و نماینده محتوای اصلی صفحه باشد. اگر داده ساختاریافته چیزی را بگوید که صفحه به کاربر نشان نمی دهد، احتمالاً داری مسیر اشتباه می ری. قوانین مهم:

• داده باید نماینده محتوای اصلی صفحه باشد: اگر صفحه درباره خدمات سئو است، Schema رویداد یا محصول فیزیکی براش نساز.
• محتوای Schema باید برای کاربر قابل مشاهده باشد: اگر FAQ داخل JSON-LD هست، سوال و جواب باید در صفحه هم دیده شود.
• داده نباید گمراه کننده باشد: Review جعلی، قیمت غیرواقعی یا اطلاعات سازمانی اشتباه، خطرناک اند.
• فیلدهای required باید کامل باشند: اگر برای یک rich result فیلدهای ضروری را نداری، صفحه eligible نمی‌شود.

• تصاویر باید قابل Crawl و مرتبط باشند: اگر image در Schema معرفی می کنی، گوگل باید بتواند آن را ببیند و تصویر باید به همان محتوا مربوط باشد.
• صفحه نباید برای Googlebot بلاک باشد: اگر صفحه با robots.txt یا noindex از دسترس خارج شده، Structured Data هم درست دیده نمی شود. گوگل در General Structured Data Guidelines میگه Structured Data باید تصویر واقعی محتوای صفحه باشد، اطلاعات پنهان از کاربر نباید Markup شود و صفحات دارای structured data نباید با robots.txt، noindex یا روش های مشابه از دسترس Googlebot خارج شوند.

اسکیما را روی چه صفحاتی نباید اضافه کنیم؟

در صفحات تکراری ابتدا نسخه اصلی را با تگ Canonical مشخص کنید و سپس اسکیما را فقط روی URL نهایی و قابل اتکا نگه دارید.

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

• صفحات Thin Content : اگر صفحه دو پاراگراف ضعیف دارد، Article Schema آن را مقاله ارزشمند نمی کند. اول محتوا را درست کن.
• صفحات بدون داده قابل مشاهده: اگر FAQ، قیمت، امتیاز یا نویسنده در صفحه نیست، در Schema هم نباید باشد.
• صفحات تکراری یا پارامتردار بی ارزش: اگر صفحه باید canonical به نسخه اصلی بدهد یا اصلاً ایندکس نشود، Schema جداگانه معمولاً اولویت نیست.
• صفحات تست، پیش نمایش یا داخلی: این ها نباید وارد فضای ایندکس و structured data عمومی شوند.
• صفحات با اطلاعات ناپایدار و بدون اتصال به دیتابیس واقعی: مثلاً قیمت محصولی که در صفحه تغییر می کند ولی Schema دستی ثابت مانده. این یکی خیلی راحت خراب می شود.

نمونه فرضی: یک صفحه خدماتی داری که فقط نوشته ما طراحی سایت انجام می دهیم، تماس . بگیرید بعد برایش Service Schema کامل با امتیاز، قیمت، Review و جزئیات عجیب می سازی. این کار نه حرفه ایه، نه پایدار. اول صفحه را کامل کن، بعد Schema بزن.

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

نمونه فرضی: یک سایت فروشگاهی Product Schema را پیاده کرده بود. Rich Results Test هم کد را Valid نشان می داد. اما در نتایج گوگل، اطلاعات محصول نمایش نمی گرفت. تیم فکر می کرد مشکل از گوگله، ولی وقتی صفحه را دقیق تر بررسی کردیم، چند مسئله مشخص شد:

• قیمت در Schema با قیمت قابل مشاهده صفحه یکی نبود.
• بعضی محصولات ناموجود هنوز InStock . بودند
• تصویر معرفی شده در Schema با تصویر اصلی صفحه فرق داشت.
• امتیاز کاربران در Schema بود، اما در صفحه به کاربر نمایش داده نمی شد.
• چند URL پارامتردار همان محصول هم Schema مشابه داشتند.
• Canonical بعضی نسخه ها درست تنظیم نشده بود. کاری که باید انجام شود: 1 . Schema به دیتای واقعی محصول وصل شود. 2 . قیمت، موجودی و تصویر از همان منبع صفحه خوانده شوند. 3 . Review فقط وقتی اضافه شود که در صفحه قابل مشاهده و واقعی است. 4 . URL های پارامتردار canonical درست بگیرند. 5 . فقط URL محصول اصلی در Sitemap بماند. 6 . بعد از اصلاح، چند URL نمونه با Rich Results Test و URL Inspection بررسی شوند. 7 . Search Console برای Product snippets یا Merchant listings پایش شود. نتیجه ای که انتظار داریم این نیست که فردا صبح همه محصولات Rich Result . بگیرند انتظار منطقی اینه که خطاها کم شوند، داده ها با صفحه هماهنگ شوند و سایت برای نمایش درست تر آماده شود. اسکیما اول باید سالم باشد؛ نمایش Rich Result مرحله بعدی است.

اعداد خوب، متوسط و ضعیف برای بررسی وضعیت اسکیما

برای Schema Markup درصد ثابت و جهانی وجود ندارد. معیار اصلی این است که صفحات مهم، اسکیماهای صحیح و هماهنگ با محتوای قابل مشاهده داشته باشند.

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

اشتباهات رایج در Schema Markup

بیشتر اشتباهات اسکیما از اینجا میاد که تیم ها دنبال گرفتن Rich Result سریع اند، نه ساخت داده دقیق. نتیجه؟ کدی که شاید ابزارها بعضی جاها قبول کنند، اما با واقعیت صفحه نمی خواند. اشتباهات مهم:

• اضافه کردن Schema : نامرتبط مثلاً استفاده از Product Schema برای صفحه خدماتی فقط چون فکر می کنی ستاره و قیمت جذابه. این کار می تونه misleading باشد.
• گذاشتن Review : جعلی Review باید واقعی، قابل مشاهده و مرتبط باشد. امتیاز ۵ از ۵ ساختگی، سئو نیست؛ خودزنیه.
• ناهماهنگی قیمت و موجودی: در فروشگاه ها زیاد می بینیم. صفحه نوشته ناموجود، Schema نوشته موجود. یا قیمت صفحه ۳ میلیون است، Schema چیز دیگری میگه.
• استفاده از FAQ های پنهان: سوالات داخل Schema هستن ولی در صفحه دیده نمی شن. این خلاف منطق Structured Data است.
• تکرار چند نوع Schema : متناقض یک صفحه هم Article است، هم Product، هم FAQ، هم LocalBusiness، هم Course؛ بدون اینکه واقعاً این ها در صفحه معنا داشته باشند. شلوغی یعنی کیفیت؟ نه.
• کپی کد از سایت دیگر: کد Schema باید مطابق اطلاعات صفحه تو باشد. کپی کردن نمونه کد و فراموش کردن تغییر URL، نام برند یا تاریخ، خطای خیلی رایجیه.
• تست نکردن بعد از تغییر قالب: یک آپدیت قالب یا افزونه می تونه کل Schema را خراب کند. بعد تیم محتوا ۶ ماه بعد می فهمه Article Schema از کار افتاده.
• استفاده از داده قدیمی: تاریخ، قیمت، موجودی، نویسنده و تصویر باید با صفحه فعلی بخوانند. Schema قبرستان داده های قدیمی نیست.

نکته: اسکیما هر چقدر هم فنی به نظر بیاد، در نهایت درباره صداقت داده است. اگر چیزی را برای کاربر نشان نمی دی، برای گوگل هم تعریفش نکن.

چک لیست افزودن و بررسی Schema Markup

قبل از انتشار Schema یا بعد از Audit، این چک لیست را برو. اگر چند موردش مبهمه، اول اصلاح کن، بعد دنبال Rich Result باش.

1. نوع صفحه دقیقاً مشخص است؟
2. Schema انتخاب شده با محتوای صفحه هماهنگه؟
3. داده های داخل Schema برای کاربر قابل مشاهده اند؟
4. فرمت JSON-LD بدون خطای Syntax است؟
5. URL ها Absolute و درست هستند؟
6. تصویرها Crawlable و مرتبط اند؟
7. نویسنده، ناشر و تاریخ ها واقعی اند؟
8. قیمت و موجودی از منبع واقعی خوانده می شوند؟
9. Review و Rating ساختگی نیستند؟
10. FAQ ها در صفحه دیده می شوند؟
11. صفحه با robots.txt یا noindex بلاک نشده؟
12. Schema روی URL canonical قرار دارد؟
13. صفحات duplicate داده متناقض ندارند؟
14. Rich Results Test خطای جدی نشان نمی دهد؟
15. Schema Markup Validator خطای ساختاری ندارد؟
16. URL Inspection نشان می دهد گوگل داده را می بیند؟
17. Search Console برای خطاهای structured data بررسی می شود؟
18. بعد از تغییر قالب یا افزونه، اسکیما دوباره تست شده؟
19. Schema با Search Intent صفحه همخوانی دارد؟
20. هیچ داده ای فقط برای فریب SERP اضافه نشده؟ اگر فقط مورد ۳ و ۹ را رعایت کنی، از خیلی ها جلوتری. داده ای که کاربر نمی بیند و واقعی نیست، نباید توی Schema باشد. به همین سادگی، به همین مهمی.

Schema Markup در وردپرس چطور اضافه می شود؟

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

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

• افزونه های سئو مثل Rank Math یا Yoast : برای سایت های کوچک و متوسط معمولاً شروع خوبی اند. Article، Breadcrumb، Organization و بعضی Schema های پایه را راحت تر مدیریت می کنند. اما باید تنظیمات را دقیق چک کنی؛ نصب افزونه یعنی کار تمام نیست.
• افزونه های تخصصی Schema : وقتی به کنترل بیشتری روی Product، FAQ، LocalBusiness یا انواع خاص نیاز داری، ممکنه افزونه تخصصی بهتر باشد. مشکلش اینه که اگر با افزونه سئو تداخل داشته باشد، چند Schema تکراری تولید می شود.
• کدنویسی سفارشی: برای سایت های جدی تر، فروشگاه های بزرگ یا ساختارهای خاص بهتره Schema از دیتابیس واقعی خوانده شود. این روش زمان برتره، اما خطای دستی کمتر می شود. نمونه فرضی: اگر سایت وردپرسی خدماتی داری، احتمالاً Organization، WebSite، Breadcrumb و Article را با افزونه خوب مدیریت می کنی. اما اگر فروشگاه داری و قیمت و موجودی سریع تغییر می کند، بهتره Product Schema به داده واقعی ووکامرس وصل شود؛ نه اینکه دستی واردش کنی و بعد فراموشش کنی.

Schema Markup برای هوش مصنوعی و AI Search مهم است؟

Structured Data برای AI Search هم می تونه مفید باشد، چون کمک می کند موجودیت ها، ویژگی ها و رابطه ها واضح تر شوند. اما نباید فکر کنیم اسکیما به تنهایی باعث می شود در پاسخ های هوش مصنوعی دیده شویم. AI Search هم به محتوا، اعتبار، برند، داده های ساختاریافته، لینک ها، موجودیت ها و کیفیت پاسخ نگاه می کند.

در فضای جدید سرچ، داده ماشینی تمیز اهمیت بیشتری پیدا کرده. وقتی درباره برند، نویسنده، محصول، قیمت، نقد، مقاله، سازمان یا مسیر صفحه داده دقیق داری، ماشین ها راحت تر می تونن بفهمن با چه چیزی طرف اند. اما باز همان قانون قبلی برقرار است: داده ساختاریافته باید نماینده واقعیت صفحه باشد. نکته: اگر سایتت پر از محتوای سطحی و بی اعتماد باشد، اسکیما فقط ظاهر ماشین خوان بهش می دهد. AI Search هم مثل گوگل سنتی، در نهایت به کیفیت منبع و پاسخ نیاز دارد.

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