چرا Schema باید یک نمودار باشد • Yoast

بیشتر و بیشتر افراد و توسعه دهندگان بیشتر و بیشتر در مورد داده های ساخت یافته و Schema.org صحبت می کنند. ما مدت زیادی در Yoast درباره Schema صحبت کرده و صحبت کرده‌ایم و چیزهای زیادی با آن و در بالای آن ساخته‌ایم. اخیراً، استاندارد پروتکل بلوک پیشنهادی شروع به صحبت در مورد ادغام با Schema کرده است، و تیم اصلی وردپرس نیز به آن علاقه مند است. این بحث را در Github ببینید.

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

چه نمودار خوبی به نظر می رسد

فرض کنید صفحه ای با یک مقاله داریم و آن مقاله حاوی الف است HowTo. ما فرض می کنیم که HowTo دلیل وجودی مقاله است. نمودار Yoast SEO ما، وقتی تجزیه می شود، به شکل زیر است:

در Article و WebPage یک یا چند نویسنده داشته باشد، تاریخ انتشار، تصاویر، وب سایت متعلق به یک سازمان باشد و غیره. تن ابرداده در طرحواره ما، که برای موتورهای جستجو بسیار مفید است. برخی از داده ها در سطح صفحه هستند (مانند زبان)، برخی از داده ها معمولاً در سطح سایت هستند (مانند ناشر)، و همه اینها به خوبی کار می کند زیرا ما همه آنها را به هم گره می زنیم.

در بسیاری از پیاده سازی های Schema، این قسمت ها هستند نه به عنوان یک نمودار به هم گره خورده است. آنها به عنوان بلوک های جداگانه به بیرون پرتاب می شوند. بنابراین به جای سلسله مراتب خوب بالا، می توانید دریافت کنید:

  • HowTo
  • Article
  • WebPage
  • WebSite

و در مورد بالا، که ممکن در واقع خوب باش من می گویم ممکن است به دلیل. چه می شود اگر HowTo در واقع تنها بخشی مماسی از است Article? مواردی وجود دارد که حتی بحرانی تر می شود. بگذارید برای شما مثالی بزنم.

وقتی طرحواره مخرب می شود

این، متأسفانه، موردی است که من در زندگی واقعی با آن مواجه شدم. یک وب سایت یک صفحه محصول برای یک محصول داشت. در زیر آن محصول، پنج محصول مرتبط، چیزهایی که معمولاً با هم خریداری می‌شوند، و غیره فهرست شده است. مؤلفه مورد استفاده برای نمایش طرح‌واره خروجی آن محصولات مرتبط برای آن پنج محصول. به بقیه طرحواره صفحه ربطی نداشت. بنابراین شما این را دریافت کردید:

  • Product (محصول اصلی)
  • Product (محصول مرتبط 1)
  • Product (محصول مرتبط 2)
  • Product (محصول مرتبط 3)
  • Product (محصول مرتبط 4)
  • Product (محصول مرتبط 5)

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

رفع آن به معنای وصل کردن آن پنج بود مربوط محصولات به محصول اصلی با isRelatedTo خواص، از بین بردن Product بخشی از خروجی آنها، و سپس اعلام می شود اصلی محصول به عنوان mainEntityOfPage. نکته اینجاست که آن بلوک های محصول باید بر اساس رفتار متفاوتی داشته باشند متن نوشته و روابط آنها با بلوک های دیگر در (و اطلاعات مربوط به) صفحه. این نوعی درک است که شما باید بتوانید خروجی Schema را ایجاد کنید.

نکات جالب: چگونه همه را به هم گره می زنیم

در نمودار خود، همه عناصر را با مشخص کردن رابطه آنها به هم گره می زنیم. برای انجام این کار، به «قطعه‌های» گراف که آنها را می‌گوییم، ارجاع می‌دهیم @id. آ WebPage یک صفت دارد isPartOf، ارجاع به WebSite قطعه یک Article دارای یک isPartOf ارجاع به WebPage. در واقع یک Article به طور پیش فرض نیز یک ویژگی دارد mainEntityOfPage که به WebPage، خود را به عنوان موجودیت اصلی اعلام می کند.

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

بنابراین: بلوک ها و طرحواره ها یکی نیستند

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

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

ما به کاری که Yoast SEO در آن زمینه انجام می دهد افتخار می کنیم و یک Schema API ارائه می دهیم که به توسعه دهندگان دیگر اجازه می دهد تا با آن ارتباط برقرار کنند و پیاده سازی های خود را اضافه کنند. الف را نیز نوشته ایم پر شده مشخصات طرحواره نحوه عملکرد خروجی ما و چرایی آن. بدون این “مغز”، یک رویکرد مبتنی بر بلوک به طور معنی‌داری و با مشکل مواجه خواهد شد بدون خطر یک صفحه را توصیف کنید