آموزش جامع پیاده‌سازی دستی اسکیمای BreadcrumbList و FAQPage (همراه با کد آماده)

خب، تبریک می‌گم! تو الان کدهای اسکیمای Breadcrumb و FAQ رو آماده کردی. حس خوبیه، نه؟ مثل اینه که یه پازل سخت رو تموم کردی. اما… (و این یه «اما»ی بزرگه) از کجا بفهمیم این پازل رو درست چیدیم؟ از کجا بدونیم گوگل اصلاً می‌تونه این کد رو بخونه و خوشش میاد؟

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

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

نوشتن کد یه بخشه، مطمئن شدن از درست کار کردنش یه بخش دیگه. خوشبختانه، گوگل ابزارهای عالی و رایگانی برای این کار به ما داده.

ابزار شماره یک: استفاده از Google’s Rich Results Test برای اعتبارسنجی

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

چطور استفاده کنیم؟

خیلی ساده‌ است. تو دو تا گزینه داری:

۱. Fetch URL: آدرس صفحه‌ای که کد رو توش گذاشتی بهش می‌دی.

۲. Code: همون تیکه کد JSON-LD خودت رو (با تگ <script>) مستقیم توش کپی می‌کنی. (من معمولاً قبل از اینکه کد رو اصلاً تو سایت بذارم، اول با این گزینه تستش می‌کنم).

دنبال چی باید بگردیم؟

این ابزار به تو دو تا چیز حیاتی رو می‌گه:

• Valid (معتبر): آیا کد تو از نظر فنی درسته؟
• Eligible (واجد شرایط): آیا این کد معتبر، واجد شرایط نمایش در نتایج غنی (مثل همون ستاره‌ها، سؤالات FAQ، یا مسیر بردکرامb) هست یا نه؟

اگه تیک سبز ✅ و جمله “Page is eligible for rich results” رو دیدی، یعنی کارت رو بی‌نقص انجام دادی. برو یه قهوه برای خودت بریز! ابزار دقیقاً بهت نشون می‌ده که مثلاً ۱ اسکیمای BreadcrumbList و ۱ اسکیمای FAQPage معتبر پیدا کرده.

ابزار شماره دو: استفاده از Schema Markup Validator (برای خطاهای نحوی)

این ابزار قبلاً مال خود گوگل بود (به اسم Structured Data Testing Tool) ولی الان خود کنسرسیوم Schema.org مدیریتش می‌کنه.

تفاوتش با ابزار قبلی چیه؟

راستش رو بخوای، برای کار ما (که هدفمون گرفتن Rich Results هست)، همون ابزار اولی (Rich Results Test) کامل‌تر و مهم‌تره.

• ابزار Rich Results Test تمرکزش روی اینه که «آیا گوگل اینو تو نتایج نشون می‌ده؟»
• ابزار Schema Markup Validator تمرکزش روی اینه که «آیا کد تو، طبق کل دیکشنری عظیم Schema.org، از نظر نحوی (Syntax) درسته یا نه؟»

این ابزار دوم، بیشتر به درد وقتی می‌خوره که داری اسکیمای خیلی پیچیده یا اسکیمایی می‌نویسی که اصلاً ریچ ریزالت نداره (مثل اسکیمای Organization یا Person).

توصیه دوستانه من: اول همیشه با Rich Results Test چک کن. اگه اونجا تیک سبز گرفتی، ۹۹٪ مواقع کارت تمومه.

نحوه خواندن و رفع خطاهای رایج (مثال: Missing comma یا Missing })

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

JSON-LD به شدت به علائم نگارشی حساسه. مثل یه معلم دیکته سخت‌گیر!

• خطای رایج #۱: کامای جا افتاده یا اضافه (Missing comma or trailing comma):
  • قانون: تو JSON، هر وقت دو تا «آیتم» رو در یک سطح پشت سر هم میاری (چه دو تا فیلد مثل "position": 1 و "name": "خانه"، چه دو تا ListItem تو بردکرامب)، باید با کاما (,) از هم جدا بشن.
  • اشتباه رایج: گذاشتن کاما (,) بعد از آخرین آیتم در یک لیست.
  • مثال اشتباه:
    JSON

    {
      "@type": "ListItem",
      "position": 1,
      "name": "خانه", // <-- این کامای اضافه باعث ارور می‌شه
    }
    

  • مثال درست:
    JSON

    [
      {
        "@type": "ListItem",
        "position": 1,
        "name": "خانه" // <-- این آخریه، نباید کاما داشته باشه
      }, // <-- این کاما لازمه، چون یه آیتم دیگه بعدش میاد
      {
        "@type": "ListItem",
        "position": 2,
        "name": "وبلاگ" // <-- اینم آخریه، کاما نمیخواد
      }
    ]
    

• خطای رایج #۲: آکولاد یا کروشه جا افتاده (Missing } or ]):
  • یادته گفتم JSON مثل جعبه‌های تودرتوئه؟ هر جعبه‌ای (آکولاد { یا کروشه [) که باز می‌کنی، باید دقیقاً همون‌جا که باید، ببندیش.
  • تجربه من: معمولاً آدم آکولاد (}) یا کروشه (]) آخر رو یادش می‌ره. ابزارهای تست دقیقاً بهت می‌گن ‘Unexpected character’ یا ‘Missing }’. فقط کافیه با دقت جعبه‌ها رو چک کنی و مطمئن شی هر درِ بازی، یه درِ بسته هم داره.

چگونه هر دو اسکیما (Breadcrumb و FAQ) را در یک صفحه قرار دهیم؟ (آیا در یک تگ <script> باشند؟)

اینم یه سوال فوق‌العاده مهم و فنی. خب، من هم اسکیمای بردکرامب رو دارم و هم FAQ. چطور هردوش رو به گوگل بدم؟

تو دو تا راه داری که هردوش کاملاً درسته، ولی یکیش یه کم تمیزتره.

راه اول: دو تگ اسکریپت جدا (روش رایج و ساده)

می‌تونی خیلی راحت، دو تا تگ <script> جدا تو <head> بذاری. یکی کامل برای BreadcrumbList و یکی کامل برای FAQPage.

<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    // ... بقیه کد بردکرامب ...
  }
</script>

<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    // ... بقیه کد FAQ ...
  }
</script>

این روش عالی کار می‌کنه. گوگل هردوش رو می‌خونه، می‌فهمه و ادغام می‌کنه.

راه دوم: ادغام در یک تگ (روش حرفه‌ای‌تر و تمیزتر)

اگه مثل من یکم وسواس تمیزی کد داشته باشی، می‌تونی هردوش رو تو یک تگ <script> بذاری. چطوری؟ با استفاده از یه «آرایه» (Array یا همون لیست) در سطح بالا.

تو می‌تونی به جای اینکه کد رو با { شروع کنی، با [ (علامت کروشه) شروع کنی و هردو اسکیمات رو به عنوان دو تا آیتم تو این لیست بذاری.

کد نمونه (روش ادغامی):

<script type="application/ld+json">
[
  {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
      // ... آیتم‌های بردکرامب ...
    ]
  },
  {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
      // ... آیتم‌های سوال و جواب ...
    ]
  }
]
</script>

دقت کن که چطور بین دو آکولاد بسته (}) و باز ({) یه کاما (,) گذاشتم، چون اینا دو تا آیتم داخل یه آرایه ([]) هستن.

کدومش بهتره؟

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

جمع‌بندی نهایی

خب، اینم از این! ما با هم تو این چند بخش یاد گرفتیم که چرا کنترل دستی اسکیما مهمه، چطور بردکرامب و FAQ رو (که دوتا از پرکاربردترین‌ها هستن) مو به مو پیاده کنیم، و در نهایت چطور کدمون رو تست کنیم که ازش مطمئن باشیم.

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

حالا تو بهم بگو، بعد از این گپ‌وگفت، بزرگترین ترسی که از کدنویسی دستی اسکیما داشتی و الان برات راحت‌تر شده، چیه؟ یا چه اسکیمای دیگه‌ای هست که دوست داری با هم بریم سراغش (مثل اسکیما Product یا Article)؟ برام بنویس.