اسکیما در سئو چیست و چگونه نوع مناسب را انتخاب کنیم؟ راهنمای وردپرس، تفاوت اعتبار کد با نتیجه ویژه و روش تست و کنترل خروجی.

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

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

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

واژگان، کد صفحه و نتیجه گوگل را جدا ببینید

Schema.org واژگان عمومی توصیف داده است. داده ساختاریافته صفحه، اطلاعاتی است که سایت تولید می کند. نتیجه ویژه گوگل یک قابلیت جدا با شرایط و سیاست های خاص است. وجود یک نوع در Schema.org به معنای پشتیبانی آن برای نتیجه ویژه نیست؛ اعتبار کد نیز نمایش ویژه یا افزایش رتبه را تضمین نمی کند.

نوع مناسب را انتخاب کنید

صفحه	نوع قابل بررسی	داده مهم
مقاله آموزشی	Article یا BlogPosting	عنوان، نویسنده، تصویر و تاریخ واقعی
محصول قابل خرید	Product و اطلاعات پیشنهاد	نام، قیمت و موجودی مطابق صفحه
معرفی سازمان	Organization	هویت و نشانی وب واقعی
مسیر مرور	BreadcrumbList	رده ها و لینک های درست

این جدول دستور افزودن همه نوع ها به همه صفحه ها نیست. صفحه خدمات را صرفا برای گرفتن ستاره به محصول دارای امتیاز ساختگی تبدیل نکنید. نظر و قیمت باید واقعی و با سیاست ویژگی مربوط سازگار باشد. برای متن آموزشی، BlogPosting انتخاب مناسبی است؛ NewsArticle برای هر مقاله لازم نیست.

از خروجی موجود وردپرس شروع کنید

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

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

نمونه ساده برای فهم ساختار

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

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "عنوان واقعی مقاله",
  "author": {
    "@type": "Person",
    "name": "نام واقعی نویسنده"
  }
}

JSON-LD فرمت پیشنهادی گوگل است. در HTML واقعی، قالب یا افزونه داده را داخل اسکریپت با نوع application/ld+json قرار می دهد؛ این نمونه فقط نمایش ساختار است. یک عنوان و تصویر ثابت را در همه مقاله ها تکرار نکنید.

تست ساختار با تست قابلیت گوگل فرق دارد

Schema Markup Validator برای بررسی ساختار و واژگان Schema.org مفید است. Rich Results Test نشان می دهد گوگل چه نوع های پشتیبانی شده ای تشخیص داده و چه خطاهایی دارند. نبود نتیجه در ابزار دوم همیشه به معنای نامعتبر بودن همه داده نیست؛ ممکن است آن نوع قابلیت نمایشی پشتیبانی شده نداشته باشد.

برای پیش نویس پشت ورود، از ورودی کد تست استفاده کنید.
پس از انتشار، URL عمومی را بررسی کنید تا خروجی واقعی دیده شود.
خطای ضروری را با هشدار تکمیلی یکی ندانید.
پس از تغییر قالب یا افزونه، نمونه های هر نوع صفحه را دوباره تست کنید.

صحت داده را دستی هم بررسی کنید

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

برای انتخاب اسکیما، ماهیت صفحه را مشخص کنید

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

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

در سایت خدماتی، فرق معرفی شرکت با معرفی یک صفحه خدمت را روشن کنید. اطلاعات سازمان ممکن است در سطح سایت کاربرد داشته باشد، اما توضیح هر صفحه باید به همان صفحه مربوط باشد. انتخاب نوع خاص تر فقط وقتی معنی دارد که تعریف و ویژگی های آن با موجودیت واقعی سازگار باشد. همچنین پشتیبانی یک نوع در واژگان Schema.org، به تنهایی به معنی وجود نمایش ویژه متناظر در گوگل نیست. این دو لایه را جدا بررسی کنید.

تفاوت داده، اعتبارسنجی و نمایش در نتایج

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

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

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

پیشگیری از خروجی تکراری در وردپرس

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

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

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

یک سناریوی عملی برای مقاله آموزشی

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

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

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

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

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

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