فرض کنید صفحه ای با یک مقاله داریم و آن مقاله حاوی الف است HowTo. ما فرض می کنیم که HowTo دلیل وجودی مقاله است. نمودار Yoast SEO ما، وقتی تجزیه می شود، به شکل زیر است:
اگر الف اضافه کنید HowTo به آن ترکیب، خود را اعلام می کند mainEntityOfPage از Article. اگر HowTo بخشی از صفحه ای است که خروجی ندارد Article طرحواره، همین کار را انجام می دهد اما به طور خودکار خودش را به عنوان ضمیمه می کند mainEntityOfPage از WebPage. به این ترتیب، یک موتور جستجو می تواند نمودار را تجزیه کند و ببیند دقیقا چه خبره. این بدان معنی است که هر بلوک باید از زمینه خود در هنگام ارائه طرحواره خود آگاه باشد.
بنابراین: بلوک ها و طرحواره ها یکی نیستند
Joost de Valk بنیانگذار Yoast است. پس از فروش Yoast او فعالیت تمام وقت خود را متوقف کرد و اکنون به عنوان مشاور شرکت عمل می کند. او یک کارآفرین اینترنتی است که به همراه همسرش ماریکه به طور فعال در چندین استارتاپ سرمایه گذاری کرده و به آنها مشاوره می دهد. تخصص اصلی او توسعه نرم افزار منبع باز و بازاریابی دیجیتال است.
بیشتر و بیشتر افراد و توسعه دهندگان بیشتر و بیشتر در مورد داده های ساخت یافته و Schema.org صحبت می کنند. ما مدت زیادی در Yoast در مورد Schema صحبت کرده و صحبت کردهایم و چیزهای زیادی با و در بالای آن ساختهایم. اخیراً پیشنهاد شده است پروتکل بلوک استاندارد شروع به صحبت در مورد ادغام با Schema کرد و تیم اصلی وردپرس نیز به این موضوع علاقه نشان می دهد. دیدن این بحث در Github.
در بسیاری از پیاده سازی های Schema، این قسمت ها هستند نه به عنوان یک نمودار به هم گره خورده است. آنها به عنوان بلوک های جداگانه به بیرون پرتاب می شوند. بنابراین به جای سلسله مراتب خوب بالا، شما می توانید:
HowTo
Article
WebPage
WebSite
و در مورد بالا، که ممکن در واقع خوب باش به دلیلی می گویم شاید چه می شود اگر HowTo در واقع فقط یک بخش مماسی از Article? مواردی وجود دارد که حتی بحرانی تر می شود. بگذارید برای شما مثالی بزنم.
وقتی طرحواره مخرب می شود
را Article و WebPage یک یا چند نویسنده داشته باشد، تاریخ انتشار، تصاویر، وب سایت متعلق به یک سازمان باشد، و غیره. تن ابرداده در طرحواره ما، که برای موتورهای جستجو بسیار مفید است. برخی از دادهها در سطح صفحه هستند (مانند زبان)، برخی از دادهها معمولاً در سطح سایت هستند (مانند ناشر)، و همه اینها خوب کار میکند، زیرا همه آنها را به هم گره میزنیم.
ابرداده Schema.org یک نسخه قابل خواندن و تفسیر توسط ماشین از آنچه در یک صفحه است است. ما در Yoast به نشانه گذاری طرحواره ای که Yoast SEO ایجاد می کند بسیار افتخار می کنیم. دلیل اصلی اینکه ما به آن افتخار می کنیم این است که تمام تلاش خود را می کنیم تا اطمینان حاصل کنیم که وقتی یک ماشین آن را می خواند، آن را به درستی تفسیر می کند. برای انجام این کار، ما تعیین کردهایم که Schema باید همیشه بودن یک نمودار به هم پیوسته.
چه نمودار خوبی به نظر می رسد
Product schema مسئول دریافت قطعات زیبای غنی از سایت است که رتبه بندی ستاره ها، قیمت و در دسترس بودن محصولات را در نتایج جستجو نشان می دهد. در این مورد، موتورهای جستجو نمی دانستند کدام محصول را انتخاب کنند. در واقع، ابزار تست نتایج غنی گوگل حتی به شما نتیجه ای نمی دهد. وقتی به این طرح و طرح خارج از چارچوب طراحی آن نگاه می کنید، هیچ راهی برای دانستن اینکه محصول اصلی در صفحه کدام محصول است وجود ندارد. زیرا طرحواره در یک نمودار به هم گره خورده است. نتیجه از بین رفتن ریچ اسنیپت برای این صفحات است. تغییری که مستقیماً به از دست دادن فروش نسبت داده می شد.
متأسفانه این موردی است که من در زندگی واقعی با آن مواجه شدم. یک وب سایت یک صفحه محصول برای یک محصول داشت. در زیر آن محصول، پنج محصول مرتبط، چیزهایی که معمولاً با هم خریداری میشوند، و غیره فهرست شده است. مؤلفه مورد استفاده برای نمایش طرحواره خروجی آن محصولات مرتبط برای آن پنج محصول. به بقیه طرحواره صفحه ربطی نداشت. بنابراین شما این را دریافت کردید:
Product (محصول اصلی)
Product (محصول مرتبط 1)
Product (محصول مرتبط 2)
Product (محصول مرتبط 3)
Product (محصول مرتبط 4)
Product (محصول مرتبط 5)
در حالی که بلوک ها در ویرایشگر جدید وردپرس هستند عالی برای استفاده با Schema، آنها به یک سطح اضافی تجزیه و یک لایه نیاز دارند منطق کسب و کار تا به بقیه صفحه گره بخورد. متأسفانه، این کار به این سادگی نیست که فقط برای هر بلوک یک طرحواره تولید کنید و آن را به همان اندازه رها کنید. ایده ای که در حال حاضر در هسته وردپرس GitHub مورد بحث قرار می گیرد، برای گره زدن طرحواره به الگوها، به نظر من، کمی هم ساده است. من نمی گویم نمی توان این کار را انجام داد، اما به کار بیشتری نیاز دارد. همین امر در مورد بحث های پیرامون پروتکل بلوک نیز صادق است.
اگر میخواهید Schema را پیادهسازی کنید، باید بخواهید و بتوانید کل زمینه یک صفحه را تعیین کنید. این منطق تجاری پیچیده، به هم پیوسته است و به طور مداوم در حال تکامل است، زیرا گوگل و سایر مصرف کنندگان استانداردهای خود را تغییر داده و تکامل می دهند. این منطق نمی تواند در هر بلوک منفرد، در قطعات منفرد زندگی کند. به یک “مغز” نیاز دارد که تمام اجزای متحرک را درک کند و بتواند نمودار منسجمی از تمام آن قطعات متحرک را توصیف کند.
ما به کاری که Yoast SEO در آن زمینه انجام می دهد افتخار می کنیم و یک Schema API ارائه می دهیم که به توسعه دهندگان دیگر اجازه می دهد تا با آن ارتباط برقرار کنند و پیاده سازی های خود را اضافه کنند. الف را نیز نوشته ایم پر شده مشخصات طرحواره نحوه عملکرد خروجی ما و چرایی آن. بدون این “مغز”، یک رویکرد مبتنی بر بلوک به طور معناداری و بدون خطر یک صفحه را توصیف کنید
جوست دی والک
در نمودار خود، همه عناصر را با مشخص کردن رابطه آنها به هم گره می زنیم. برای انجام این کار، به «قطعههای» گراف که آنها را میگوییم، ارجاع میدهیم @id. آ WebPage یک ویژگی دارد isPartOf، ارجاع به WebSite قطعه یک Article دارای یک isPartOf ارجاع به WebPage. در واقع، یک Article به طور پیش فرض نیز یک ویژگی دارد mainEntityOfPage که به WebPage، خود را به عنوان موجودیت اصلی اعلام می کند.
رفع آن به معنای وصل کردن آن پنج بود مربوط محصولات به محصول اصلی با isRelatedTo خواص، از بین بردن Product بخشی از خروجی آنها، و سپس اعلام می شود اصلی محصول به عنوان mainEntityOfPage. نکته اینجاست که آن بلوک های محصول باید بر اساس آن رفتار متفاوتی داشته باشند متن نوشته و روابط آنها با بلوک های دیگر در (و اطلاعات مربوط به) صفحه. این نوعی درک است که شما باید بتوانید خروجی Schema را ایجاد کنید.