سلام رفیق! تا حالا شده حس کنی با اینکه همه کارها رو درست انجام دادی لینکسازی داخلی کردی، محتوای طولانی نوشتی و کیوردها رو تارگت کردی باز هم گوگل گیج میزنه؟ انگار نمیفهمه کدوم صفحه مادره و کدوم بچهست. راستش رو بخوای، لینکهای آبی توی متن خوبن، اما کافی نیستن. گوگل دنبال یه “نقشه مهندسی” میگرده، نه فقط چند تا تابلو راهنما.
توی این مقاله قراره دقیقا دست بذاریم روی همون نقشه مهندسی یا همون دادههای ساختاریافته (Schema Markup). من میخوام بهت یاد بدم چطور با نکات پیشرفته و تکنیکها پیلارکلاستر، یه معماری بینقص برای سایتت بسازی که گوگل عاشقش بشه و رتبههات رو بیمه کنه. آمادهای سیمکشیهای مخفی سایتت رو درست کنیم؟
جدول راهنمای سریع: تفاوت استراتژی اسکیما در پیلار و کلاستر
قبل از اینکه بریم سراغ کدها، این جدول رو ببین تا بدونی برای هر نوع صفحه باید چه لباسی بدوزی:
| ویژگی | صفحه پیلار (Pillar Page) | صفحه کلاستر (Cluster Page) |
| نوع اصلی اسکیما | CollectionPage یا Article (با توجه به ماهیت) |
Article یا BlogPosting |
| ویژگی کلیدی | ItemList (برای لیست کردن فرزندان) |
isPartOf (برای اشاره به مادر) |
| هدف استراتژیک | معرفی به عنوان “مرجع” و “هاب” موضوعی | انتقال اعتبار و جزئیات به صفحه مادر |
| اتصال معنایی | استفاده از mainEntity برای موضوع کلان |
استفاده از about برای اتصال به پیلار |
| خطر اصلی | عدم آپدیت dateModified بعد از تغییرات |
لینکدهی اشتباه در Breadcrumb |
معماری اسکیمای پیلار-کلاستر؛ چگونه گوگل رابطه محتوای مادر و فرزند را درک میکند؟
بذار یه اعترافی بکنم؛ اوایل کارم فکر میکردم اگه از صفحه کلاستر به پیلار لینک بدم، کار تمومه. اما یه پروژه داشتم که تو حوزه گردشگری بود. ما صدها مقاله (کلاستر) درباره جاهای دیدنی شیراز داشتیم و یک صفحه اصلی (پیلار) برای “سفر به شیراز”. با وجود لینکسازی عالی، گوگل مدام صفحات کلاستر رو برای کلمات کلیدی اصلیِ پیلار رتبهبندی میکرد. کلافه شده بودم!
اونجا بود که فهمیدم گوگل به یه «نقشه راه» دقیقتر نیاز داره. گوگل باهوشه، اما ذهنخوان نیست. وقتی ما از اسکیمای سلسلهمراتبی استفاده میکنیم، داریم با زبان خود گوگل (JSON-LD) باهاش حرف میزنیم.
در واقع، ما با این کدها به خزنده گوگل (Crawler) میگیم:
-
«آهای گوگل! این صفحه (پیلار)، سرپرستِ این خانوادهست.»
-
«این صفحات (کلاسترها)، بچههای این خانوادهن و بخشی از این کل هستن.»
این درک رابطه مادر و فرزندی، باعث میشه اعتبار (Authority) کلِ اون موضوع تو سایتت بره بالا، نه فقط یک صفحه خاص.
گذار از لینکسازی داخلی بصری به اتصالات معنایی (Semantic Connections) در کد
لینکهای آبی توی متن (Hyperlinks) عالیان، ولی یه مشکلی دارن: بصری و ناپایدارن. ممکنه جای لینک عوض شه، انکر تکست تغییر کنه یا اصلاً کاربر روش کلیک نکنه. اما «اتصالات معنایی» توی کد، ثابت و محکمن.
من توی استراتژیهام، وقتی میخوام یه کلاستر رو به پیلار وصل کنم، دیگه فقط به لینک داخلی اکتفا نمیکنم. ما میآیم از پراپرتیهایی مثل isPartOf یا hasPart در اسکیما استفاده میکنیم.
-
در صفحه کلاستر: با استفاده از
isPartOf، آدرس صفحه پیلار رو به عنوان مجموعه مادر معرفی میکنیم. این یعنی به گوگل میگیم: “هویت این مقاله، وابسته به اون صفحه اصلیه.” -
در صفحه پیلار: میتونیم از
ItemListاستفاده کنیم تا لیست تمام کلاسترهای زیرمجموعه رو به صورت ساختاریافته به گوگل نشون بدیم.
این کار باعث میشه گوگل درک کنه که اینها جزایر جداافتاده نیستن، بلکه یک «موجودیت واحد و به هم پیوسته» (Unified Entity) هستن. اینجاست که معجزه سئو معنایی اتفاق میافته.
نقش اسکیمای سلسلهمراتبی در جلوگیری از کنیبالیزیشن (Keyword Cannibalization)
این یکی از اون دردهاییه که فکر کنم همهمون حداقل یک بار تجربهش کردیم: همنوعخواری یا کنیبالیزیشن!
یادمه یه مشتری داشتم تو حوزه فروش موبایل. صفحه دستهبندی “خرید آیفون” با مقاله “راهنمای خرید آیفون” مدام با هم درگیر بودن. یک روز این لینک یک بود، فردا اون یکی. عملاً داشتن همدیگه رو میخوردن!
وقتی ما از اسکیمای درست استفاده میکنیم، داریم عملاً جلوی این دعوای خانوادگی رو میگیریم. چطوری؟
با تعریف دقیق سلسلهمراتب در اسکیما (مثلاً استفاده از CollectionPage برای پیلار و Article یا ItemPage برای کلاسترها)، به گوگل میفهمونیم که:
-
پیلار (Pillar): برای کلمات کلیدی عمومی، کلی و با اینتنت “Transactional” یا “Navigation” هست.
-
کلاستر (Cluster): برای کلمات کلیدی لانگتیل (Long-tail) و با اینتنت “Informational” هست.
وقتی این مرزبندی توی کد مشخص باشه، گوگل دیگه گیج نمیشه که کدوم صفحه رو برای کدوم کوئری بیاره بالا. هر کسی سر جای خودش میشینه و این یعنی پایان جنگ داخلی سایت!
تأثیر دادههای ساختاریافته بر تشکیل گراف دانش (Knowledge Graph) اختصاصی سایت
حالا میرسیم به بخش جذاب ماجرا که من عاشقشم: ساختن امپراتوری خودت.
هدف نهایی ما در “وزیر سئو” این نیست که فقط چند تا کلمه کلیدی رو بیاریم بالا؛ هدف ما اینه که سایت شما تبدیل به یک Reference بشه.
وقتی شما بهطور مداوم و صحیح از دادههای ساختاریافته (Structured Data) برای اتصال محتواها استفاده میکنید، گوگل کمکم شروع میکنه به ساختن یک «گراف دانش» کوچک برای سایت شما. گوگل میفهمه که:
-
موجودیت (Entity) “نگین شیخ الاسلامی” نویسنده این مقالهست.
-
این مقاله بخشی از موضوع بزرگتر “سئو تکنیکال” هست.
-
موضوع “سئو تکنیکال” یکی از خدمات اصلی برند “وزیر سئو” هست.
این درک عمیق باعث میشه که گوگل سایت شما رو به عنوان یک منبع متخصص (Expert) بشناسه. نتیجهش؟
-
حضور در بخشهای ویژه نتایج جستجو (Rich Snippets).
-
افزایش چشمگیر E-E-A-T (چون تخصص و اعتبار سایت اثبات شده).
-
و از همه مهمتر، پایداری رتبهها در آپدیتهای هسته گوگل.
استراتژی انتخاب نوع اسکیما (Schema Type) برای صفحه پیلار (The Pillar)
خیلیها فکر میکنن همین که کد اسکیما رو کپی-پیست کنن توی هدر سایت، کار تمومه. ولی توی “وزیر سئو”، ما روی این قضیه وسواس داریم. چرا؟ چون نوع اسکیمایی که انتخاب میکنی، به گوگل میگه که “جنس” این صفحه چیه.
آیا این صفحه یه مقاله طولانیه که باید خونده بشه؟ یا یه لیست از منابع مختلفه که قراره کاربر رو هدایت کنه؟ استراتژی من اینه: «ماهیت صفحه رو نگاه کن، نه اسمش رو.»
استفاده از اسکیمای CollectionPage در مقابل Article؛ کدام برای پیلار شما مناسبتر است؟
این یکی از اون دو راهیهاییه که همیشه سرش بحثه. بذار تجربهم رو بهت بگم:
-
اسکیمای
ArticleیاBlogPosting: اگر صفحه پیلار تو، خودش یک مقاله جامع و طولانیه (مثلاً “راهنمای جامع صفر تا صد سئو”) که کاربر توش میمونه و ۲۰۰۰ کلمه متن میخونه، قطعا جایگاهشArticleهست. گوگل این صفحات رو به عنوان محتوای خواندنی میشناسه و شانس گرفتن Rich Snippetهای متنی رو داری. -
اسکیمای
CollectionPage: اما اگر صفحه پیلار تو بیشتر شبیه یه “هاب” یا “دستهبندی” طراحی شده که چند خط توضیح داره و بعدش لیستی از مقالات کلاستر رو نشون میده، اینجاCollectionPageانتخاب هوشمندانهتریه.
توصیه خواهرانه من: اکثر پیلارهای مدرن، ترکیبی هستن. یعنی هم متن طولانی دارن و هم لینکدهی زیاد. من معمولاً سمت Article میرم تا قدرت محتوایی رو حفظ کنم، اما با استفاده از پراپرتیهایی که پایینتر میگم، اون حس “مجموعه بودن” رو هم به گوگل القا میکنم. اینجوری با یه تیر دو نشون میزنی.
پیادهسازی ویژگی ItemList برای معرفی رسمی مقالات کلاستر به گوگل
حالا میرسیم به اون چسب جادویی که پیلار رو به کلاسترها وصل میکنه. اگر از من بپرسی مهمترین بخش اسکیمای پیلار چیه، میگم ItemList.
لینکسازی داخلی خوبه، ولی ItemList مثل “لیست حضور و غیاب رسمی” کلاسه. وقتی تو داخل اسکیمای صفحه پیلار، از ItemList استفاده میکنی و URL تمام مقالات کلاستر (فرزندان) رو توش لیست میکنی، داری رسماً به گوگل اعلام میکنی:
«گوگل جان! این ۱۰ تا مقالهای که اینجا لیست کردم، صرفاً چندتا لینک تصادفی نیستن؛ اینها اجزای تشکیلدهنده این پیلار هستن. اینها یک تیمان!»
من بارها دیدم که با اضافه کردن همین لیست ساده به کد اسکیما، ایندکس شدن مقالات کلاستر (که گاهی گیر میکردن) مثل بنز راه افتاده. چرا؟ چون اعتبار صفحه مادر مستقیم و بدون واسطه بهشون تزریق شده.
تعریف ویژگی mainEntity برای تمرکز قدرت موضوعی روی کلمه کلیدی اصلی
و اما ضربه نهایی! تا حالا شده حس کنی گوگل دقیقاً نمیدونه صفحه پیلارت درباره “چی” هست؟ مثلاً پیلار نوشتی درباره “دیجیتال مارکتینگ”، ولی با “خدمات سئو” میاد بالا؟
اینجاست که mainEntity (یا در نسخههای جدیدتر استفاده از پراپرتی about) وارد بازی میشه.
ما نباید بذاریم گوگل حدس بزنه. ما باید بهش دیکته کنیم.
توی اسکیمای پیلار، من همیشه یک بخش about تعریف میکنم و اون رو وصل میکنم به یک Entity شناخته شده (مثلاً لینک ویکیدیتا یا نالج گراف گوگل مربوط به اون موضوع).
-
مثال: اگر پیلار من درباره “قهوه” است، من توی اسکیما با استفاده از
sameAsبه صفحه ویکیپدیای “Coffee” لینک میدم.
این کار باعث میشه تمام قدرت و اعتباری که این صفحه و کلاسترهاش جمع میکنن، مثل لیزر متمرکز بشه روی اون مفهوم اصلی. این یعنی جلوگیری از هدر رفتن انرژی سئو و فهمیدن دقیق موضوع توسط هوش مصنوعی گوگل.
پیکربندی اسکیمای صفحات کلاستر (Cluster Pages) برای انتقال اعتبار
وقتی من دارم روی اسکیمای یک صفحه کلاستر (مثلاً یک مقاله بلاگ با کلمه کلیدی طولانی) کار میکنم، ذهنیتم اینه: «این صفحه مستقل نیست؛ این صفحه فقط یک قطعه از یک پازل بزرگتره.»
تمام هدف تنظیمات اسکیما در اینجا اینه که این “وابستگی” رو به گوگل اثبات کنیم تا گوگل بفهمه که رشد این صفحه، یعنی رشد صفحه پیلار.
استفاده از ویژگی isPartOf برای اتصال صریح کلاستر به صفحه پیلار در کدهای JSON-LD
این شاید یکی از “فوتهای کوزهگری” باشه که کمتر کسی بهش دقت میکنه.
به طور پیشفرض، اکثر افزونههای سئو، ویژگی isPartOf رو توی اسکیمای صفحات به آدرس “صفحه اصلی سایت” (Homepage) وصل میکنن. این اشتباه نیست، اما عالی هم نیست.
من برای اینکه رابطه مادر-فرزندی رو برای گوگل شفاف کنم، میام و این کد رو دستکاری میکنم:
در اسکیمای صفحه کلاستر، مقدار isPartOf رو تغییر میدم تا مستقیماً به URL صفحه پیلار اشاره کنه (یا حداقل پیلار رو به عنوان بخشی از زنجیره معرفی میکنم).
با این کار، عملاً به ربات گوگل میگم:
«ببین، درسته که این مقاله توی سایت وزیر سئو منتشر شده، اما صاحباختیار مستقیمش و مجموعهای که بهش تعلق داره، اون صفحه پیلاره.»
این تکنیک باعث میشه وقتی کلاستر شما رتبه میگیره، “لینک جویس” (Link Juice) و اعتبار معناییش با سرعت و کیفیت خیلی بیشتری به پیلار منتقل بشه.
اهمیت حیاتی اسکیمای BreadcrumbList در ترسیم دقیق ساختار درختی سایت
بردکرامب (خرده نان) فقط اون لینکهای بالای صفحه نیست که کاربر روش کلیک کنه؛ بردکرامب در واقع نقشه مختصات سایت شماست.
مشکلی که زیاد میبینم اینه که بردکرامبها صرفاً بر اساس ساختار URL چیده شدن (مثلاً: خانه > بلاگ > مقاله). این برای سئو معمولی بد نیست، اما برای معماری پیلار-کلاستر کافی نیست.
توی پروژههای حساس، من ساختار اسکیمای BreadcrumbList رو جوری میچینم که ساختار موضوعی (Topical) رو نشون بده، نه فقط ساختار فیزیکی رو.
یعنی مسیر باید به این شکل تعریف بشه:
خانه > [صفحه پیلار/موضوع اصلی] > [صفحه کلاستر/مقاله فعلی]
وقتی اسکیمای بردکرامب به این شکل باشه، گوگل دقیقاً متوجه میشه که این مقاله زیرشاخهی اون موضوع کلیه. اینجاست که ساختار درختی سایتت توی دیتابیس گوگل شکل میگیره و گوگل میفهمه که تو توی اون موضوع خاص (پیلار)، چقدر محتوای عمیق و گسترده داری.
تقویت سیگنالهای E-E-A-T در کلاسترها با فیلدهای Author، ReviewedBy و Citation
رسیدیم به بخش مورد علاقه من: اعتماد سازی!
صفحات کلاستر معمولاً جایی هستن که ما داریم به سوالات دقیق و جزئی کاربر جواب میدیم. اینجا جاییه که باید نشون بدیم “ما اینکارهایم”.
گوگل عاشق اینه که بدونه پشت این محتوا کیه. توی اسکیمای کلاستر، پر کردن فیلد Article یا BlogPosting با اطلاعات زیر حیاتیه:
-
Author(نویسنده): فقط نوشتن اسم “ادمین” فاجعهست! من همیشه اسم واقعی نویسنده رو با لینک به صفحه پروفایلش (که توش تخصصهاش لیست شده) میذارم. این یعنی “تخصص” (Expertise). -
ReviewedBy(بازبینی شده توسط): اگر تو حوزههای حساس مثل سلامتی یا مالی (YMYL) کار میکنی، این فیلد حکم طلا رو داره. اضافه کردن اسم یک متخصص که مقاله رو تایید کرده، سیگنال “اعتماد” (Trustworthiness) رو به سقف میچسبونه. -
Citation(ارجاعات): اگر توی مقالهت ادعایی کردی، توی اسکیما با فیلدcitationبه منبع معتبرش لینک بده. این کار به گوگل نشون میده که محتوای تو “تحقیق شده” و معتبره.
وقتی تکتک کلاسترهای تو این سیگنالهای E-E-A-T رو داشته باشن، برآیند کلیشون باعث میشه که صفحه پیلارِ تو، به عنوان یک مرجع بیرقیب و قابل اعتماد شناخته بشه.
تکنیکهای پیشرفته اسکیمای تو در تو (Nested Schema) در معماری محتوا
اسکیمای تو در تو یعنی چی؟ یعنی به جای اینکه بگیم “این صفحه یه مقاله است” و جداگانه بگیم “این صفحه یه ویدیو داره”، بیایم و ویدیو رو داخل دلِ مقاله تعریف کنیم. اینطوری رابطه اجزا حفظ میشه.
اما بیایم این رو توی معماری پیلار-کلاستر بررسی کنیم.
استفاده از ویژگی about و mentions برای اتصال کلاسترها به موجودیتهای ویکیدیتا (Wikidata)
بذار یه راز بزرگ رو بهت بگم: گوگل دیگه به کلمات کلیدی فکر نمیکنه، به «موجودیتها» (Entities) فکر میکنه.
وقتی تو یه مقاله کلاستر درباره “قهوه عربیکا” مینویسی، گوگل باید بفهمه که منظورت دقیقاً همون نوع قهوهای هست که توی دایرهالمعارف جهانی ثبت شده، نه یه اسم مندرآوردی.
برای این کار، ما از دو ویژگی شاهکار توی اسکیما استفاده میکنیم و اونها رو به ویکیدیتا (Wikidata) یا ویکیپدیا وصل میکنیم:
-
ویژگی
about(درباره): این رو برای موضوع اصلی مقاله کلاستر استفاده میکنیم.-
مثال: اگر مقالهت درباره “ایلان ماسک” هست، توی اسکیما
aboutرو لینک میدی به صفحه ویکیدیتای ایلان ماسک. این یعنی: “گوگل جان، این مقاله دقیقاً و مستقیماً درباره همین آدمه.”
-
-
ویژگی
mentions(اشاره شده): این برای موضوعات فرعی که توی مقاله دربارهشون حرف زدی استفاده میشه.-
مثال: توی همون مقاله ایلان ماسک، درباره “تسلا” و “اسپیس ایکس” هم حرف زدی. اینها رو میذاری توی
mentionsو لینک میدی به ویکیدیتاشون.
-
نتیجه؟ گوگل گراف دانش سایت تو رو به گراف دانش جهانی وصل میکنه. این یعنی اعتبار خالص! سایتت دیگه یه جزیره تنها نیست، بلکه وصل شده به اقیانوس اطلاعات معتبر وب.
پیادهسازی اسکیمای FAQPage در پیلار برای پوشش سوالات پرتکرار کلاسترها
یه اشتباه رایج اینه که دوستان فکر میکنن FAQPage فقط مال صفحه “سوالات متداول” سایته. نه عزیزم!
صفحه پیلار تو باید پاسخدهنده نهایی باشه.
استراتژی من اینه:
من میرم سوالات مهم و پرتکراری که توی تکتک کلاسترها جواب دادم رو جمع میکنم، و گلچینی از اونها رو (مثلاً ۵ تا ۱۰ تا از مهمترینها) میارم توی صفحه پیلار. اما نه فقط به صورت متن!
من اینها رو توی اسکیمای FAQPage صفحه پیلار جاسازی میکنم.
چرا این کار رو میکنم؟
-
تصاحب فضای گوگل (Pixel Real Estate): وقتی پیلار تو با اسکیمای سوالات متداول میاد بالا، فضای بیشتری توی نتایج جستجو (SERP) میگیره و رقبای پایینتر رو هل میده پایین.
-
مرجعیت: به کاربر (و گوگل) نشون میدی که این صفحه پیلار، جواب تمام سوالات ریز و درشت این حوزه رو داره.
نکته فنی مهم: دقت کن که متن سوال و جواب توی اسکیما، باید عیناً توی صفحه پیلار هم دیده بشه (Hidden Content نباشه) تا گوگل جریمهت نکنه.
ادغام اسکیمای VideoObject و ImageObject برای کلاسترهای چندرسانهای
محتوای خشک و خالی متنی دیگه قدیمی شده. کلاسترهای ما پر از عکسهای اختصاصی، اینفوگرافیک و ویدیوهای آموزشیان. حیف نیست گوگل اینها رو نبینه؟
خیلیها اسکیمای ویدیو رو جداگانه میذارن. اما تکنیک “تو در تو” اینه که VideoObject یا ImageObject رو داخل ویژگی hasPart یا مستقیماً درون اسکیمای Article تعریف کنی.
-
برای ویدیو: وقتی اسکیمای ویدیو رو درست میچینی (با تعیین دقیق
thumbnailUrl,uploadDateوduration)، شانس این رو داری که ویدیوت توی تب “Videos” گوگل و حتی توی نتایج معمولی با یه تامنیل جذاب نشون داده بشه. -
برای تصاویر: اگر اینفوگرافیک خفنی توی کلاستر داری، حتماً براش
ImageObjectتعریف کن و لایسنس و خالق اثر (Creator) رو مشخص کن. این کار باعث میشه توی Google Images رتبه بگیری و ورودی تصویری سایتت منفجر بشه.
این یعنی ما از هر ذرهی محتوایی که تولید کردیم، برای سیگنال فرستادن به گوگل استفاده میکنیم. هیچی نباید هدر بره!
اشتباهات فنی رایج در نشانهگذاری پیلار و کلاستر که باید از آنها اجتناب کنید
سئو تکنیکال مثل ریاضیه؛ یا صفره یا یک. یا کدت درسته و گوگل رو هدایت میکنه، یا غلطه و گمش میکنه. توی معماری پیلار-کلاستر، چون صفحات به هم وابستهن، خطا توی یکی، بقیه رو هم خراب میکنه.
تضاد دادهها (Data Conflict) بین اسکیمای بردکرامب و ساختار URL
این رایجترین اشتباهیه که میبینم و اسمش رو گذاشتم «اسکیزوفرنی دیجیتال»!
داستان از این قراره:
ساختار URL فیزیکی سایت شما (مثلاً در وردپرس) ممکنه فلت (Flat) باشه:
example.com/blog/article-name
اما شما میای توی اسکیمای BreadcrumbList، یه مسیر مجازی تعریف میکنی تا ساختار پیلار رو نشون بدی:
Home > Blog > SEO Training (Pillar) > Technical SEO (Cluster)
کجای کار ایراد داره؟
ایراد زمانی پیش میاد که لینکهایی که توی اسکیما میذاری، با واقعیت سایتت نخونه.
-
لینک به ناکجاآباد: توی بردکرامب به دستهای لینک میدی که وجود خارجی نداره یا ریدایرکت میشه.
-
تناقض با Canonical: یوآرالی که توی
idبردکرامب معرفی میکنی، با تگ کنونیکال اون صفحه فرق داره.
چرا خطرناکه؟ گوگل وقتی ببینه “نقشه راهی” که دادی (Breadcrumb) با “آدرسی” که وجود داره (URL) در تضاده، اعتمادش رو به دیتای ساختاریافتهت از دست میده.
راه حل من: اگر ساختار URLهات فلت هست، ایرادی نداره که بردکرامب سلسلهمراتبی باشه، به شرطی که هر آیتمی که توی بردکرامب لینک میشه، واقعاً یک صفحه زنده، ایندکسبل و سالم باشه (ترجیحاً خود صفحه پیلار).
استفاده اشتباه از اسکیمای Carousel برای لیست کردن مقالات کلاستر
یه زمانی مد شد که سئوکارها فکر میکردن اگر لیست مقالات کلاستر رو توی اسکیمای ItemList بذارن و فرمت Carousel (اسکرولی) بهش بدن، گوگل نتایجشون رو توی سرچ خوشگل نشون میده.
خبر بد: گوگل برای مقالات معمولی وبلاگ (Informational Articles)، از ریچ ریزالتِ Carousel پشتیبانی نمیکنه (مگر اینکه News, Recipe, Course یا Movie باشه).
وقتی شما به زور سعی میکنید مقالات آموزشی کلاستر رو توی قالب Carousel به گوگل قالب کنید، دو تا اتفاق میفته:
-
خطای سرچ کنسول: ممکنه ارورهای عجیبغریب بگیرید چون فیلدهای اجباری اون نوعهای خاص رو ندارید.
-
نادیده گرفته شدن: گوگل کلاً اون قطعه کد رو نادیده میگیره و حتی ممکنه به عنوان Spammy Structured Data (تلاش برای دستکاری نتایج) علامتگذاری بشید.
توصیه خواهرانه: برای معرفی کلاسترها در صفحه پیلار، از همون ItemList ساده و استاندارد استفاده کنید. هدف ما اینجا فهموندن ساختاره، نه گرفتنِ زورکیِ یک ریچ اسنیپت که مال ما نیست. ساده و استاندارد بازی کنید تا برنده بشید.
عدم بهروزرسانی dateModified در اسکیمای پیلار هنگام افزودن کلاستر جدید
این مورد «قاتل خاموش» استراتژی محتوایی شماست.
فرض کن تو یه صفحه پیلار داری و امروز یه مقاله کلاستر جدید و خفن نوشتی و لینکشو اضافه کردی به پیلار.
لینکسازی داخلی رو انجام دادی، اما…
توی کدهای اسکیما (یا حتی تنظیمات صفحه)، تاریخ dateModified صفحه پیلار رو آپدیت نکردی.
چه اتفاقی میفته؟
خزنده گوگل میاد سراغ پیلار، هدر HTTP یا تگهای اسکیما رو چک میکنه و میبینه تاریخ تغییر نکرده. پیش خودش میگه: «خب، اینجا که خبری نیست، برم سراغ کارم.»
نتیجه؟ اون لینک جدیدی که ساختی، ممکنه روزها یا هفتهها طول بکشه تا توسط گوگل از طریق پیلار کشف بشه.
قانون طلایی من: هر بار، تاکید میکنم هر بار که یه لینک کلاستر به پیلار اضافه میکنی یا تغییری توی لیست ItemList میدی، باید dateModified صفحه پیلار به روز بشه. این یعنی زنگ زدن به گوگل و گفتنِ:
«آهای گوگل! من اینجا یه چیزی رو تغییر دادم، بدو بیا ببین!»
این کار باعث میشه «فرشنس» (Freshness) محتوای پیلارت حفظ بشه و کلاسترهای جدیدت با سرعت جت ایندکس بشن.
چکلیست نهایی تست و اعتبارسنجی کدهای اسکیما
تست اسکیما فقط برای این نیست که ببینیم ارور قرمز داریم یا نه؛ برای اینه که مطمئن بشیم داستانی که برای گوگل تعریف کردیم، همون چیزیه که توی ذهنمون بود. گاهی کد درسته، ولی منطقش غلطه. این چکلیست، بیمهنامه زحمات توئه.
بررسی خطاهای سینتکس با Schema.org Validator
اولین ایستگاه ما، ابزار کلاسیک Schema Markup Validator (که قبلاً مال گوگل بود و الان دست خودِ Schema.org هست) محسوب میشه. این ابزار مثل معلم دیکتهست؛ کاری نداره محتوا چیه، فقط چک میکنه ببینه قواعد گرامری زبان JSON-LD رو رعایت کردی یا نه.
من وقتی کد رو اینجا تست میکنم، دنبال این ۳ مورد میگردم:
-
شکار ارورهای سینتکسی: یه ویرگولِ جاافتاده یا یه کوتیشنِ بسته نشده، کل کد رو منفجر میکنه. این ابزار دقیقاً خطی که مشکل داره رو نشون میده.
-
چک کردن ساختار تو در تو (Nesting): اینجا باید دقت کنی. آیا
ItemListدقیقاً زیرمجموعه پیلار قرار گرفته؟ آیا ویدیو (VideoObject) درست توی دل مقاله نشسته؟-
نکته کنکوری من: روی دکمههای فلش کنار هر آیتم کلیک کن و ساختار درختی رو باز کن. باید دقیقاً مثل معماریای که روی کاغذ کشیدی باشه. اگه یه آیتم “بیرون” افتاده، یعنی ساختار اسکیمات شکسته.
-
-
تطبیق دادهها: چک کن که URLها، تیترها و توضیحات، دقیقاً همونهایی باشن که توی صفحه هستن. اگر توی اسکیما نوشتی “نویسنده: نگین” ولی توی صفحه اسمی نیست، این یه سیگنال منفیه.
آنالیز نمایش نتایج غنی با ابزار Rich Results Test گوگل
خب، کد ما از نظر گرامری درسته (Valid). اما آیا از نظر گوگل هم جذابه (Eligible)؟
اینجاست که ابزار Rich Results Test وارد میدون میشه. این ابزار دیدگاهِ اختصاصیِ گوگل رو نشون میده و بهت میگه آیا این صفحه لیاقت گرفتن ستاره، عکس یا لیستهای ویژه رو توی نتایج جستجو داره یا نه.
چکلیست من برای این ابزار:
-
بررسی هشدارهای نارنجی (Warnings): ارورهای قرمز (Errors) که تکلیفشون روشنه، باید رفع بشن. اما هشدارهای نارنجی (مثل Missing field ‘brand’) رو نادیده نگیر. توی رقابتهای سنگین سئو، همین جزئیاتِ اختیاری باعث میشن گوگل دیتای کاملتری ازت داشته باشه و تو رو بالاتر نشون بده.
-
تست نسخه موبایل و دسکتاپ: حتماً هر دو رو چک کن. گاهی کدهای اسکیما بخاطر نوع طراحی سایت، توی نسخه موبایل درست رندر نمیشن.
-
پیشنمایش (Preview): این دکمه جادویی رو بزن! ببین گوگل دقیقاً چه شکلی میخواد تو رو نشون بده. آیا عکس تامنیل ویدیوت درست کراپ شده؟ آیا سوالات FAQ درست لیست شدن؟
-
تجربه شخصی: یه بار همه چیز سبز بود، ولی توی پیشنمایش دیدم که تایتلِ اسکیمای مقاله خیلی طولانیه و سه نقطه (…) میخوره. همونجا اصلاحش کردیم و نرخ کلیک (CTR) رو نجات دادیم.
-
جمعبندی: پایان سردرگمی گوگل
خب، رسیدیم به ته خط. دیدی؟ استفاده از اسکیما در پیلار کلاستر اونقدرها هم که فکر میکردیم ترسناک نبود. ما فقط داریم با زبونی که گوگل بهتر میفهمه (JSON-LD) بهش میگیم: “ببین، این صفحه رئیسه و اینها هم تیمش هستن.”
یادت باشه، سئو فقط نوشتن نیست؛ سئو یعنی “مهندسی اطلاعات”. وقتی تو با استفاده از ItemList و isPartOf این ساختار رو محکم میکنی، دیگه نگران کنیبالیزیشن یا گم شدن صفحات جدیدت نیستی. تو یه امپراتوری منظم ساختی.
حالا نوبت توئه. همین الان برو سراغ یکی از پیلارهای اصلی سایتت و کدهاش رو چک کن. آیا گوگل داره صدای تو رو واضح میشنوه یا فقط زمزمهها رو میگیره؟ اگر سوالی داشتی، من همینجام تا با هم حلش کنیم.