برای سئو پادکست، هر اپیزود یک صفحهٔ مستقل با عنوان روشن، پلیر قابل‌استفاده، خلاصه و متن بازبینی‌شده داشته باشد. فایل صوتی، صفحهٔ وب و فید پادکست را با هم اشتباه نگیرید. اسکیمای PodcastEpisode باید همین محتوای واقعی را توصیف کند؛ افزودن آن، نمایش ویژه یا رتبه را تضمین نمی‌کند.
وقتی مخاطب جمله‌ای از یک گفت‌وگوی صوتی را جست‌وجو می‌کند، صفحهٔ اپیزود باید بتواند پاسخ را به او نشان دهد. یک پلیر تنها، مسیر پیدا کردن آن جمله را توضیح نمی‌دهد. عنوان موضوعی، خلاصهٔ دقیق، متن پیاده‌شده و زمان شروع بحث، برای چنین مراجعه‌ای کاربرد دارند. سئو پادکست در وب از همین صفحه شروع می‌شود.
در این راهنما، منظور از پادکست مجموعه‌ای از اپیزودهای صوتی است که برای هر قسمت، صفحهٔ وب هم دارید. رتبه‌گرفتن داخل اپلیکیشن‌های شنیدن پادکست، مسئلهٔ جداگانه‌ای است. دستورهای صفحهٔ وب را بدون بررسی، به جست‌وجوی داخلی یک اپلیکیشن تعمیم ندهید.
سئو پادکست دقیقاً کدام صفحه را هدف می‌گیرد؟
سئو پادکست برای سایت، بهینه‌سازی صفحهای است که یک اپیزود مشخص را معرفی می‌کند و امکان شنیدن یا خواندن آن را می‌دهد. صفحهٔ مجموعه همهٔ قسمت‌ها را کنار هم می‌گذارد، اما صفحهٔ اپیزود باید به موضوع همان گفت‌وگو پاسخ دهد. نام مجموعه، شمارهٔ قسمت و موضوع بحث را روشن و قابل تشخیص بنویسید.
سه نوع نشانی را در کارتان جدا ثبت کنید: صفحهٔ مجموعه، صفحهٔ اپیزود و فایل صوتی. کاربر در صفحهٔ مجموعه موضوع‌های مختلف را مرور می‌کند. در صفحهٔ اپیزود، دربارهٔ یک گفت‌وگو تصمیم می‌گیرد. نشانی فایل، خود صدا را تحویل می‌دهد. فرستادن همهٔ لینک‌ها به فایل صوتی، معرفی مهمان و متن همراه را از این مسیر حذف می‌کند.
پیش از ساخت صفحه، عنوان‌های آرشیو را مرور کنید. اگر مقاله‌ای از قبل «انتخاب میکروفون برای ضبط در خانه» را آموزش می‌دهد، صفحهٔ گفت‌وگو باید زاویهٔ مشخص خودش را داشته باشد؛ مثلاً «تجربهٔ ضبط خانگی با میکروفون USB». فقط تبدیل قالب متن به صوت، موضوع مستقل ایجاد نمی‌کند. دربارهٔ تفاوت تجربهٔ مهمان، پرسش‌ها و مثال‌های اپیزود بنویسید.
برای تدوین متن همراه، همان اصول سئو محتوا کاربرد دارد: یک نیاز مشخص، توضیح قابل‌فهم و اطلاعاتی که واقعاً در اپیزود مطرح شده است. تکرار عبارت «سئو پادکست» در نام هر قسمت، وقتی بحث دربارهٔ موضوع دیگری است، معرفی آن را مبهم می‌کند.
عنوان و خلاصهٔ اپیزود را چطور بنویسیم؟
عنوان اپیزود باید موضوع و زاویهٔ بحث را مشخص کند؛ شمارهٔ قسمت و نام مجموعه اطلاعات تکمیلی‌اند. خلاصه نیز توضیح می‌دهد شنونده چه پرسشی را در این گفت‌وگو دنبال می‌کند و مهمان چه تجربه‌ای مطرح کرده است. عنوان جذابِ نامفهوم یا توضیح یکسان برای همهٔ قسمت‌ها، انتخاب اپیزود مناسب را دشوار می‌کند.
«قسمت ۱۸: یک گفت‌وگوی متفاوت» برای کسی که مجموعه را نمی‌شناسد، موضوعی ندارد. اگر اپیزود دربارهٔ نویز اتاق است، «کاهش نویز در ضبط خانگی؛ گفت‌وگو دربارهٔ اتاق و میکروفون» روشن‌تر است. شمارهٔ قسمت را در جای ثابت صفحه بنویسید. برای مهمان هم نام و نقش واقعی کافی است؛ لقب تخصصی یا سابقه‌ای که تأیید نشده اضافه نکنید.
خلاصه را از فایل نهایی بسازید و به یک پرسش اصلی محدود کنید. برای نمونه، اگر بحث دربارهٔ بازتاب صدا در اتاق معمولی است، همین شرایط را بنویسید؛ نام چند مدل میکروفون در گفت‌وگو، آن را به آزمون مقایسه‌ای محصولات تبدیل نمی‌کند. نام مهمان، دلیل حضور او و موضوع‌هایی که واقعاً پاسخ داده، برای معرفی کافی است.
صفحهٔ مقاله و اپیزود را هم از نظر کاربرد مقایسه کنید. مقاله میتواند دستورهای مرحله‌به‌مرحله داشته باشد؛ گفت‌وگو ممکن است تصمیم‌ها و محدودیت‌های تجربهٔ مهمان را شرح دهد. در معرفی اپیزود، همین تفاوت را توضیح دهید و به امید گرفتن همان عبارت، متن مقاله را زیر پلیر کپی نکنید.
توضیح متا را جداگانه و فشرده تنظیم کنید. این توضیح جای متن صفحه را نمی‌گیرد و الزاماً عیناً در نتیجهٔ جست‌وجو نمایش داده نمی‌شود. از وعده‌هایی مثل «رتبهٔ اول با یک اپیزود» یا عددهای بی‌پشتوانه برای افزایش شنونده استفاده نکنید. برای کاور نیز موضوع یا هویت مجموعه را نشان دهید و عنوان را فقط داخل عکس نگذارید.
صفحهٔ اپیزود چه اجزایی داشته باشد؟
صفحهٔ اپیزود باید در ابتدای خود عنوان، خلاصهٔ کوتاه و پلیر قابل‌استفاده داشته باشد؛ بعد، اطلاعات مهمان، موضوع‌های گفت‌وگو و متن همراه را ارائه کند. مدت و تاریخ انتشار را از فایل و سابقهٔ واقعی بردارید. مخاطب موبایل نباید برای فهمیدن موضوع یا شروع شنیدن، از چند باکس و پیشنهاد عبور کند.
پلیر را با صفحه‌کلید و گوشی آزمایش کنید. دکمهٔ پخش باید نام قابل‌فهم داشته باشد، کنترل صدا و جابه‌جایی زمان کار کند و پخش خودکار مزاحم شروع نشود. اگر پلیر یک سرویس بیرونی بارگذاری نمی‌شود، خلاصه و متن صفحه همچنان باید خواندنی باشند. وابسته‌کردن همهٔ محتوا به همان قاب، دسترسی را شکننده می‌کند.
فهرست زمان‌ها را براساس فایل نهایی بنویسید. در یک نمونهٔ آموزشی، «۰۲:۱۰، چرا صدای اتاق بازتاب دارد؟» از «بخش دوم» اطلاعات بیشتری می‌دهد. زمان‌ها باید بعد از حذف مقدمه یا تدوین دوباره اصلاح شوند. اگر پلیر قابلیت پرش ندارد، زمان را به شکل متن نمایش دهید و از ساختن دکمه‌ای که کار نمی‌کند پرهیز کنید.
اگر برای همین قسمت نسخهٔ تصویری هم دارید، رابطهٔ دو نسخه را روشن کنید. قواعد صفحهٔ دارای تصویر و ویدئو را در راهنمای بهینه‌سازی ویدئوی سایت بررسی کنید. وجود نسخهٔ ویدئویی، دلیل کافی برای درج VideoObject روی صفحهای که فقط صوت دارد نیست.
متن پیاده‌شده را چطور بازبینی کنیم؟
متن پیاده‌شده باید محتوای صوت را درست منتقل کند و معلوم باشد چه کسی صحبت می‌کند. خروجی تبدیل گفتار به متن را پیش‌نویس بگیرید؛ نامها، عددها، اصطلاحات و جمله‌های ناقص را با شنیدن فایل اصلاح کنید. اگر متن را کوتاه یا بازنویسی کرده‌اید، آن را خلاصه یا نسخهٔ ویرایششده بنامید، نه متن کامل گفت‌وگو.
در راهنمای دسترس‌پذیری صوت ضبط‌شده از W3C، متن جایگزین یکی از روش‌های دسترسی به محتوای صوتی است. این راهنما می‌گوید «text supports the ability to search for non-text content»؛ یعنی متن، جست‌وجوی محتوای غیرمتنی را ممکن می‌کند. این توصیه دربارهٔ دسترسی و استفاده از محتواست و درصد افزایش رتبه بیان نمی‌کند.
متن را با برچسب گوینده و پاراگراف‌های کوتاه منتشر کنید. زمان را در شروع موضوع‌های مهم بگذارید؛ لازم نیست هر جمله یک زمان جدا داشته باشد. صدای معنادار، مثل خنده‌ای که لحن پاسخ را عوض می‌کند، ممکن است برای فهم گفت‌وگو لازم باشد. تکرار همهٔ مکث‌های بی‌اثر، خواندن متن را سخت می‌کند.
برای بازبینی، فایل صوتی و متن را کنار هم باز کنید. از ابتدای فایل تا پایان پیش بروید و هر نوبت صحبت را به گویندهٔ درست نسبت دهید. نام مهمان، برند دستگاه و اصطلاحات را با اطلاعات تأییدشده تطبیق دهید. عددها را دوباره گوش کنید؛ حذف یک «نه» یا جابه‌جایی یک رقم میتواند معنی پاسخ را عوض کند.
در نمونهٔ فرضیِ گفت‌وگو دربارهٔ نویز، اگر گوینده می‌گوید «این میکروفون نویز اتاق را حذف نمی‌کند»، متن «این میکروفون نویز اتاق را حذف می‌کند» مردود است. همین جملهٔ کوتاه معیار کنترل خوبی است: بازبین فقط غلط املایی را نمی‌گیرد، صحت ادعا و نفی جمله را هم بررسی می‌کند. این مثال، گزارش آزمون محصول یا تجربهٔ مشتری نیست.
اگر بخشی نامفهوم است، حدس را به مهمان نسبت ندهید. از او توضیح بخواهید یا نامفهوم‌بودن بخش را صریح ثبت کنید. نسخهٔ ویرایششده میتواند مکث و تکرار بی‌اثر را حذف کند، اما نباید پاسخ تازه‌ای بسازد. بازبین تاریخ ویرایش و نسخهٔ فایل مرجع را در پروندهٔ داخلی اپیزود نگه دارد.
متن را در HTML قابلخواندن صفحه قرار دهید. فایل دانلودی میتواند گزینهٔ تکمیلی باشد. اگر متن داخل بخش بازشونده است، محتوایش باید واقعاً در صفحه وجود داشته باشد و کاربر بتواند با صفحه‌کلید آن را باز کند. نمایش متن در یک عکس یا صرفاً داخل پلیر بیرونی، معادل متن صفحه نیست.
اسکیما پادکست را با چه داده‌ای بسازیم؟
اسکیمای پادکست باید اپیزود، مجموعه و فایل صوتی را با اطلاعات واقعی توصیف کند. برای اپیزود از PodcastEpisode و برای مجموعه از PodcastSeries استفاده می‌شود؛ فایل صوت میتواند AudioObject باشد. عنوان، نشانی صفحه، تاریخ و مدت باید با محتوای منتشرشده تطبیق داشته باشند. دادهٔ ساختاریافته جای پلیر، متن و معرفی قابلمشاهده را نمی‌گیرد.
در نمونهٔ رسمی PodcastEpisode در Schema.org، اپیزود با partOfSeries به مجموعه و با associatedMedia به رسانهٔ صوتی وصل شده است. همین تفکیک را در پیاده‌سازی رعایت کنید: نشانی صفحه در url با نشانی بایت‌های فایل در contentUrl یک چیز نیست. برای فایل صوتی واقعی، AudioObject توصیف مشخص‌تری دارد.
| جزء | دادهٔ مناسب | کنترل قبل از انتشار |
|---|---|---|
| اپیزود | PodcastEpisode با name و url | عنوان و نشانی همان قسمت باشد |
| مجموعه | partOfSeries با PodcastSeries | نام و نشانی مجموعه تطبیق داشته باشد |
| صوت | associatedMedia با AudioObject | contentUrl فایل قابل‌دسترسی را معرفی کند |
| تاریخ | datePublished | تاریخ انتشار اولیهٔ اپیزود باشد |
| مدت | timeRequired یا duration در رسانه | زمان واقعی فایل نهایی ثبت شود |
| زبان | inLanguage | زبان گفت‌وگو را درست بیان کند |
برای اپیزود و مجموعه، @id ثابت و متمایز تعیین کنید. اگر افزونهٔ سئو و افزونهٔ پادکست هر دو داده تولید می‌کنند، خروجی نهایی را بررسی کنید تا دو اپیزود با عنوان یا تاریخ متفاوت معرفی نشده باشد. مدت را در قالب معتبر بنویسید؛ مثلاً PT36M یعنی ۳۶ دقیقه. این عدد نمونهٔ آموزشی است و باید با مدت فایل واقعی تطبیق داده شود.
در AudioObject، ویژگی transcript از نوع متن است؛ نشانی فایل متن را به‌جای خود متن در آن نگذارید. برای معرفی صفحهٔ اپیزود و فایل، ویژگی‌های مربوط به نشانی را درست انتخاب کنید. ثبت transcript هم جای متن خواندنی روی صفحه را نمی‌گیرد. ویژگی‌های فاقد اطلاعات را حذف کنید؛ مهمان، تعداد شنونده یا تاریخ ساختگی تولید نکنید.
برای واژگان و رابطهٔ اشیا، راهنمای اسکیما توضیح پایه را دارد. در صفحهٔ اپیزود، دادهٔ صوت را به همان فایل وصل کنید و روی مقالهٔ آموزشی دربارهٔ پادکست، یک اپیزود ساختگی تعریف نکنید. نوع داده باید موضوع واقعی همان صفحه باشد.
آیا اسکیما باعث نمایش ویژهٔ پادکست در گوگل می‌شود؟
وجود PodcastEpisode در Schema.org به معنی وجود یک نمایش ویژهٔ تضمین‌شده برای آن در گوگل نیست. اعتبار واژگان و پشتیبانی یک موتور جست‌وجو از نمایش خاص، دو بررسی جدا هستند. اسکیما را برای توصیف درست محتوا بسازید و نتیجهٔ جست‌وجو را جدا اندازه بگیرید؛ از خروجی یک ابزار، وعدهٔ رتبه یا نمایش پلیر استخراج نکنید.
در بررسی ۲۱ مهر ۱۴۰۵، گالری رسمی داده‌های ساختاریافتهٔ گوگل راهنمای مستقلی برای نتیجهٔ غنی PodcastEpisode ندارد. از این مشاهده نمی‌توان نتیجه گرفت که گوگل هیچ داده‌ای از آن نمی‌فهمد؛ فقط نباید ساختن این نوع داده را معادل دریافت نمایش ویژه معرفی کرد.
برای کنترل واژگان، Schema Markup Validator و برای قابلیت‌های پشتیبانی‌شدهٔ گوگل، Rich Results Test را به کار ببرید. اگر ابزار دوم برای این نوع، نتیجهٔ غنی تشخیص نداد، لزوماً نامعتبر بودن واژگان ثابت نشده است. دادهٔ نهایی را بعد از انتشار بخوانید؛ بعضی افزونه‌ها چیزی متفاوت از فرم تنظیمات تولید می‌کنند.
RSS را نیز با اسکیما اشتباه نگیرید. فید، اپیزودها را برای دریافت در سرویس‌های شنیدن معرفی می‌کند؛ اسکیما، اشیای صفحهٔ وب را توصیف می‌کند. انتشار صحیح در یک اپلیکیشن، سلامت صفحهٔ سایت را تأیید نمی‌کند. هر دو خروجی را با اطلاعات یک اپیزود مشخص تطبیق دهید.
پیش از انتشار، کدام خطاهای فنی را بررسی کنیم؟
پیش از انتشار، صفحهٔ اپیزود و مسیر رسیدن به آن را بررسی کنید: پاسخ سالم، نشانی اصلی درست، نبود منع ناخواستهٔ ایندکس و نمایش متن بدون ورود به حساب. پلیر و فایل صوتی را هم جدا آزمایش کنید. صفحهای که متنش باز می‌شود اما صوتش خطا دارد، هنوز برای شنونده آماده نیست.
از صفحهٔ مجموعه به هر اپیزود لینک بدهید. عنوان لینک را طوری بنویسید که موضوع قسمت مشخص باشد. در مقاله‌های مرتبط نیز فقط وقتی به اپیزود لینک بدهید که گفت‌وگو جزئیات مفیدی به همان بحث اضافه کند. انتشار صفحه بدون هیچ مسیر داخلی، مرور آرشیو را برای کاربر دشوار می‌کند.
اگر دو نشانی با محتوای یکسان دارید، تصمیم نشانی اصلی را با تیم فنی مشخص کنید. برای متن کامل اپیزود، صرفاً به دلیل طولانی بودن آن صفحهٔ دوم نسازید. تفکیک متن وقتی کاربرد دارد که نیاز مستقلی را پاسخ دهد و رابطهٔ صفحه‌ها روشن باشد. کپی‌کردن همان متن روی چند نشانی، اطلاعات بیشتری به مخاطب نمی‌دهد.
آزمون پذیرش را در یک پنجرهٔ بدون ورود به سایت انجام دهید: صفحه را باز کنید، پخش را شروع کنید، توقف بزنید و به یک زمان میانی بروید. سپس همان جمله را در متن پیدا کنید. این چهار عمل، تطبیق صفحه، فایل و متن را قابلمشاهده می‌کنند؛ فقط سالم‌بودن پیش‌نمایش ویرایشگر کافی نیست.
فایل دانلودی را هم جدا بررسی کنید، اگر چنین گزینه‌ای دارید. نشانی خصوصی یا موقت ممکن است امروز باز شود و بعداً از کار بیفتد. پخش فایل در موبایل با اتصال معمولی را آزمایش کنید. بارگیری کامل فایل پیش از شروع پخش، تأخیر طولانی یا قطع‌شدن در جابه‌جایی زمان را با زمان و دستگاه ثبت کنید و به مسئول پلیر تحویل دهید.
در تغییر میزبان صوت، شناسهٔ پایدار اپیزود در فید و تاریخ اولیه را حفظ کنید و رابطهٔ صفحه با فایل تازه را دوباره بسنجید. جابه‌جایی فایل، انتشار اپیزود جدید نیست. پس از هر تدوین مجدد هم مدت، زمان‌های فهرست و متن را با نسخهٔ تازه تطبیق دهید.
اگر پلیر، قالب وردپرس و خروجی اسکیما از چند ابزار می‌آیند، مسئولیت کنترل هرکدام را مشخص کنید. در برنامهٔ خدمات سئو گوگل، بررسی صفحهٔ اپیزود میتواند بخشی از کنترل فنی و محتوایی سایت باشد؛ خروجی قابل‌تحویل آن باید فهرست خطاها، نشانی صفحات و نتیجهٔ آزمون اصلاحات باشد.
اثر سئو پادکست را چطور اندازه بگیریم؟
اثر سئو پادکست را با دادهٔ صفحهٔ وب و رفتار شنیدن جدا بسنجید. نمایش و کلیک جست‌وجو، شروع پخش و رسیدن به بخش‌های بعدی، رویدادهای یکسانی نیستند. تعریف هر شاخص و محدودیت ابزار را در گزارش بنویسید. افزایش بازدید صفحه بدون پخش، به‌تنهایی افزایش مخاطب پادکست را ثابت نمی‌کند.
گزارش هر اپیزود را با نشانی صفحه و تاریخ تغییر آغاز کنید. دادهٔ جست‌وجوی همان صفحه را با یک بازهٔ قابل‌مقایسه بسنجید و عبارت‌های مراجعه را هم بخوانید. برای اپیزود کم‌مراجعه، چند کلیک بیشتر یا کمتر شواهد کافی برای اثر قطعی یک تغییر نیست. دورهٔ سنجش را براساس مقدار داده انتخاب کنید، نه یک مهلت ثابت برای همهٔ مجموعه‌ها.
تغییر عنوان، افزودن متن، اصلاح پلیر و انتشار تبلیغ را در یک خط زمان ثبت کنید. اگر همه با هم رخ داده‌اند، گزارش فقط نتیجهٔ این مجموعه تغییرها را نشان می‌دهد. برای نسبت‌دادن اثر مستقل به متن پیاده‌شده، شواهد بیشتری لازم است. نسخهٔ قبلی و تاریخ اصلاح را نگه دارید تا مقایسه قابل‌بررسی بماند.
رویداد شروع پخش را از کلیک روی لینک شنیدن جدا تعریف کنید. با یک پخش آزمایشی بررسی کنید هر رویداد چه زمانی ثبت می‌شود؛ اگر توقف و ادامهٔ همان پخش دوباره شمارش می‌شود، شمار شروع‌ها تعداد افراد نیست. تعریف نشست و روش حذف شمارش تکراری را در گزارش نگه دارید.
در پلیر بیرونی که رویداد شنیدن به سایت نمی‌فرستد، ممکن است فقط کلیک خروجی قابلاندازهگیری باشد. آن را با برچسب «کلیک رفتن به سرویس شنیدن» گزارش کنید. آمار میزبان پادکست را جدا بخوانید و بدون شناسه و روش تطبیق معتبر، جمع دو گزارش را تعداد شنوندهٔ یکتا معرفی نکنید.
اگر کاربران از جست‌وجو وارد می‌شوند اما پخش را شروع نمی‌کنند، پیش از تغییر عنوان، صفحه را بررسی کنید. پلیر دیده می‌شود؟ خلاصه با موضوع جست‌وجو تطبیق دارد؟ آیا متن پاسخ را داده و کاربر نیازی به شنیدن ندارد؟ حالت آخر الزاماً شکست نیست. هدف اپیزود و نیاز کاربر را در تفسیر داده در نظر بگیرید.
جمع‌بندی
از یک اپیزود شروع کنید: صفحهٔ مستقل، عنوان موضوعی، پلیر سالم و متن دقیق بسازید. دادهٔ ساختاریافته را با همان صفحه و فایل تطبیق دهید و از آرشیو به آن لینک بدهید. بعد، ورود از جست‌وجو و شنیدن را جدا گزارش کنید. تعداد ویژگی‌های اسکیما، جای کیفیت گفت‌وگو و دسترسی به آن را نمی‌گیرد.
سوالات متداول
برای هر اپیزود پادکست یک صفحهٔ جدا لازم است؟
اگر هر قسمت موضوع و محتوای مشخصی دارد، صفحهٔ مستقل امکان معرفی، پخش و خواندن همان گفت‌وگو را می‌دهد. صفحهٔ مجموعه برای مرور همهٔ قسمت‌هاست. ساختن چند صفحهٔ تقریباً یکسان برای یک قسمت، هدف این تفکیک نیست.
متن خودکار پادکست را میتوان بدون ویرایش منتشر کرد؟
بهتر است ابتدا نامها، عددها، اصطلاحات و معنی جملهها را با فایل تطبیق دهید. تبدیل خودکار گفتار ممکن است این موارد را اشتباه ثبت کند. اگر متن کامل نیست، آن را خلاصه یا نسخهٔ ویرایششده معرفی کنید.
متن کامل باید در خود صفحه باشد یا فایل دانلودی کافی است؟
متن قابلخواندن در صفحه، مسیر سادهتری برای مراجعه و پیدا کردن بخش موردنظر دارد. فایل دانلودی میتواند گزینهٔ اضافه باشد. متن داخل عکس یا قاب سرویس بیرونی را با متن HTML صفحه یکی نگیرید.
PodcastEpisode رتبه یا نمایش پلیر در گوگل را تضمین می‌کند؟
خیر. این نوع، واژگانی برای توصیف اپیزود است. اعتبار اسکیما و دریافت نمایش ویژه در یک موتور جست‌وجو دو موضوع جدا هستند؛ باید پشتیبانی همان موتور و نتیجهٔ واقعی را جدا بررسی کرد.
برای پادکست صوتی از VideoObject استفاده کنیم؟
صفحهای که فقط فایل صوتی دارد نباید یک ویدئوی ساختگی معرفی کند. برای صوت میتوان از AudioObject در ارتباط با PodcastEpisode استفاده کرد. اگر نسخهٔ ویدئویی واقعی هم دارید، دادهٔ آن را با محتوای قابلمشاهده تطبیق دهید.
تعداد شروع پخش همان تعداد شنوندهٔ کامل اپیزود است؟
خیر. شروع پخش، کلیک خروجی و ادامهٔ شنیدن رویدادهای متفاوتیاند. بعضی پلیرهای بیرونی اطلاعات ادامهٔ پخش را به سایت نمیدهند؛ در چنین حالتی، گزارش باید فقط دادهٔ قابلاندازهگیری را بیان کند.
منابع
- W3C: متن جایگزین برای صوت و ویدئوی ضبط‌شده
- Schema.org: تعریف و نمونهٔ PodcastEpisode
- Google Search Central: انواع دادهٔ ساختاریافته با پشتیبانی نمایش ویژه
