اسکیما Article برای مقاله: مطابقت با محتوای واقعی

اسکیمای Article یک دادهٔ ساخت‌یافته است که اطلاعات مقاله (عنوان، نویسنده، تاریخ، تصویر) را به‌صورت قابل‌خواندن برای ماشین ارائه می‌دهد. نکتهٔ اصلی این مقاله ساده است: markup باید بازتاب واقعی همان چیزی باشد که خواننده در صفحه می‌بیند، نه نسخه‌ای «بهتر» از آن. این مقاله بر پایهٔ دو مستند رسمی Google (راهنمای Article و راهنمای عمومی داده‌های ساخت‌یافته، خوانده‌شده ۱۹ اکتبر ۲۰۲۶) ویژگی‌ها، قواعد کیفیت و روش اعتبارسنجی را شرح می‌دهد. نمونهٔ JSON-LD با دامنهٔ ساختگی و آزمون‌نشده است؛ انتخاب‌های سازمانی (مثل چه کسی نویسنده نوشته شود) تصمیم شماست. برای زمینهٔ سئو SEO در سال ۲۰۲۶ را ببینید.

Article برای چه خوب است و چه تضمین نمی‌کند

طبق راهنما، افزودن Article به صفحهٔ مقاله می‌تواند به Google کمک کند عنوان، تصویر و تاریخ را بهتر در نتایج نشان دهد. هیچ ویژگی الزامی وجود ندارد؛ هر ویژگی توصیه‌شده‌ای که برای محتوای شما صدق می‌کند را اضافه کنید. همچنین راهنمای عمومی صریحاً می‌گوید Google نمایش ویژگی‌های مبتنی بر داده ساخت‌یافته را تضمین نمی‌کند، حتی اگر Rich Results Test خطا نشان ندهد. پس هیچ‌گاه با وعدهٔ «اسکیما = رتبه یا نمایش ویژه» آن را توجیه نکنید.

ویژگی‌های توصیه‌شده

انواع پذیرفته‌شده Article، NewsArticle و BlogPosting هستند. برای یک مقالهٔ آموزشی وبلاگ، BlogPosting یا Article مناسب است؛ راهنما «مشخص‌ترین نوع قابل‌اعمال» را توصیه می‌کند.

مطابقت با محتوای واقعی صفحه

راهنمای عمومی چند قاعدهٔ کیفیت دارد که مستقیماً به موضوع ما مربوط است: markup باید نمایندهٔ واقعی محتوای صفحه باشد؛ محتوای نامرئی برای خواننده را markup نکنید؛ اطلاعات گمراه‌کننده یا نامرتبط نگذارید؛ اطلاعات به‌روز باشد. برای Article یعنی:

• headline با عنوان قابل‌مشاهدهٔ صفحه یکی باشد، نه نسخهٔ پر از کلیدواژه.
• author همان نویسنده‌ای باشد که در صفحه معرفی شده است؛ راهنما می‌گوید همهٔ نویسندگان نمایش‌داده‌شده باید در markup باشند، هر کدام در یک author جدا، و author.name فقط نام باشد (نه عنوان شغلی یا «نوشته‌شده توسط»).
• datePublished و dateModified با تاریخ‌های واقعی انتشار و ویرایش مطابقت داشته باشد. تغییر dateModified بدون تغییر محتوایی معنادار، برخلاف روح «بازنمایی واقعی» است؛ این برداشت نویسنده از قاعدهٔ مطابقت است نه جملهٔ مستقیم راهنما.
• image همان تصویر مرتبط با مقاله باشد و URL آن قابل‌خزش و ایندکس‌پذیر.

نمونهٔ JSON-LD (ساختگی)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "عنوان مقاله",
  "image": ["https://example.com/img/guide-16x9.jpg"],
  "datePublished": "2026-10-01T09:00:00+03:30",
  "dateModified": "2026-10-10T09:00:00+03:30",
  "author": [{"@type": "Person", "name": "نام نویسنده", "url": "https://example.com/authors/name"}]
}
</script>

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

اعتبارسنجی و استقرار

1. کد را با Rich Results Test بررسی کنید و خطاهای بحرانی را رفع کنید.
2. چند صفحه را مستقر کنید و با URL Inspection ببینید Google چه می‌بیند؛ صفحه نباید با robots.txt، noindex یا نیاز به ورود مسدود باشد.
3. برای اطلاع‌رسانی تغییرات آینده sitemap بفرستید.
4. زمان برای خزش مجدد بدهید؛ راهنما می‌گوید ممکن است چند روز طول بکشد.

JSON-LD فرمت توصیه‌شده است و Microdata و RDFa هم پذیرفته می‌شوند. اگر صفحهٔ تکراری دارید، راهنمای عمومی توصیه می‌کند همان داده روی همهٔ نسخه‌های تکراری باشد.

خطر نقض قواعد

راهنما می‌گوید مشکل در داده ساخت‌یافته می‌تواند به manual action بینجامد؛ این اقدام صلاحیت نمایش به‌صورت rich result را برمی‌دارد ولی طبق همان راهنما بر رتبهٔ جست‌وجوی وب اثر نمی‌گذارد. با این حال، مهم‌ترین دلیل رعایت قواعد اعتماد خواننده است: اگر نام نویسنده یا تاریخ در markup با صفحه نخواند، تناقض ساخته‌اید.

مثال ساختگی از یک ناهماهنگی و اصلاح آن

تیمی فرضی عنوان نمایشی «راهنمای انتخاب هاست» دارد، اما headline در markup «بهترین هاست ارزان ایران ۱۴۰۵ خرید هاست» است. این دو یکی نیستند و دومی کلیدواژه‌پراکنی است. اصلاح: headline همان عنوان صفحه شود. در نمونهٔ دیگر، نام نویسنده در markup «دکتر علی، مدیر فنی» است؛ طبق راهنما باید فقط نام در name بیاید و عنوان شغلی در jobTitle قرار گیرد. مثال‌ها ساختگی‌اند.

اشتباهات رایج

• headline متفاوت از عنوان صفحه.
• نویسنده‌ای در markup که در صفحه معرفی نشده.
• مقادیر مختلف dateModified بدون تغییر محتوا.
• تصویر لوگو یا تصویر نامرتبط.
• مسدودکردن صفحه با robots.txt یا noindex.
• انتظار تضمین نمایش یا رتبه از Article.

تولید markup از دادهٔ CMS

پایدارترین راه برای حفظ مطابقت، تولید JSON-LD از همان فیلدهایی است که صفحه را می‌سازند. اگر عنوان، تاریخ انتشار، تاریخ ویرایش و نویسنده در CMS ذخیره شده‌اند، قالب صفحه باید JSON-LD را از همان فیلدها بسازد و نه از متن جداگانه‌ای که دستی نگه‌داری می‌شود. این توصیهٔ مهندسی نویسنده است و هدفش حذف ناهماهنگی است. مراحل پیشنهادی:

1. فهرست فیلدهای موجود را بنویسید: عنوان، خلاصه، تصویر شاخص، نویسنده، تاریخ انتشار، تاریخ ویرایش.
2. برای هر ویژگی Article مشخص کنید از کدام فیلد می‌آید. ویژگی بدون فیلد را رها کنید؛ چون هیچ ویژگی الزامی نیست، ساختن مقدار ساختگی لازم نیست.
3. تاریخ‌ها را در فرمت ISO 8601 با منطقهٔ زمانی تبدیل کنید. راهنما می‌گوید بدون منطقهٔ زمانی، Google منطقهٔ زمانی Googlebot را پیش‌فرض می‌گیرد.
4. برای نویسنده‌های متعدد، آرایه‌ای از شیء‌های جدا بسازید، نه یک رشتهٔ ترکیبی.
5. JSON را با یک کتابخانهٔ تبدیل امن بسازید تا نویسه‌های خاص مثل گیومه در عنوان ساختار را خراب نکنند.

پس از استقرار، نمونه‌ای از صفحه‌ها را با Rich Results Test امتحان کنید و یک آزمون خودکار ساده اضافه کنید که بررسی کند headline در JSON-LD برابر عنوان صفحه است. چنین آزمونی با هر تغییر قالب از بروز ناهماهنگی جلوگیری می‌کند.

ویژگی‌های مکمل و محدودیت‌های این مقاله

راهنمای Article فقط ویژگی‌های فهرست‌شده در جدول بالا را «پشتیبانی‌شده» می‌داند. ویژگی‌های دیگر schema.org وجود دارد، ولی ما در این مقاله دربارهٔ اثر آن‌ها ادعایی نمی‌کنیم چون در مستند خوانده‌شده نبود. برای مقاله‌های چندبخشی، راهنما می‌گوید rel=canonical باید به هر صفحهٔ مجزا یا یک صفحهٔ «نمایش کامل» اشاره کند و نه به صفحهٔ اول مجموعه. اگر محتوای شما پشت ورود یا اشتراک است، راهنما به داده ساخت‌یافتهٔ محتوای اشتراکی اشاره می‌کند که در این مقاله بررسی نشده است.

عناصر دیگری مثل مسیر صفحه (breadcrumb) نیز می‌توانند همراه Article بیایند؛ راهنمای عمومی توضیح می‌دهد Google چند آیتم روی یک صفحه را، چه تودرتو چه جداگانه، می‌فهمد، به شرط اینکه نمایندهٔ محتوای واقعی صفحه باشند. اگر چنین آیتم‌هایی را اضافه می‌کنید، همان قاعدهٔ مطابقت درباره‌شان هم صادق است. این مقاله نیز تأثیر هیچ‌کدام را بر رتبه یا نمایش ادعا نمی‌کند.

چک‌لیست

1. نوع مناسب (BlogPosting یا Article) انتخاب شده است.
2. headline، author و تاریخ‌ها با محتوای قابل‌مشاهده یکی است.
3. همهٔ نویسندگان صفحه در author جدا آمده‌اند.
4. تصویر مرتبط، قابل‌خزش و در چند نسبت است.
5. تاریخ‌ها ISO 8601 با منطقهٔ زمانی‌اند.
6. با Rich Results Test و URL Inspection بررسی شده است.

منابع و مراجع

• Article (Article, NewsArticle, BlogPosting) structured data — Google Search Central، 2026-10-19.
• General structured data guidelines — Google Search Central، 2026-10-19.