سئو محتوای غیرمتنی؛ تصاویر، پادکست و اینفوگرافیک

یک اپیزود دقیق منتشر می‌کنید، اما فایل صوتی در Feed آدرس پایدار ندارد؛ یک اینفوگرافیک پرهزینه می‌سازید، اما نمودارش فقط روی Canvas دیده می‌شود؛ یا تصویر اصلی صفحه را با CSS می‌آورید و انتظار دارید در جست‌وجوی تصویر کشف شود. در این وضعیت، مشکل «کمبود کلمه کلیدی» نیست. زنجیره میان دارایی، صفحه مالک، متادیتا، دسترس‌پذیری، توزیع و اندازه‌گیری شکسته است.

سئو محتوای غیرمتنی یعنی این زنجیره را طوری طراحی کنیم که کاربر و ماشین بتوانند موضوع، مالک، نسخه، زمینه و مقصد هر تصویر، فایل صوتی یا تجربه تعاملی را بفهمند. Alt پر از کلیدواژه، Show Note با تعداد کلمه اجباری یا Schema بدون محتوای قابل‌مشاهده جای این معماری را نمی‌گیرد. این راهنما یک مدل عملیاتی برای تیم‌های محتوا، سئو، طراحی و توسعه ارائه می‌کند؛ با ملاحظات فارسی، RTL، زیرساخت و توزیع در ایران.

سئو محتوای غیرمتنی دقیقاً چه مسئله‌ای را حل می‌کند؟

کاربر ممکن است یک موضوع را در Web Search، Google Images، اپ پادکست، شبکه اجتماعی یا موتور جست‌وجوی داخل سایت پیدا کند. هر سطح ورودی، قواعد کشف و سنجش خودش را دارد. هدف این نیست که همه دارایی‌ها را به هر قیمتی در گوگل رتبه بدهیم؛ هدف این است که برای هر Intent، مسیر قابل‌کشف، قابل‌فهم و قابل‌استفاده بسازیم.

پس «غیرمتنی» به معنی «بدون متن» نیست. متن، ساختار HTML و متادیتا پل دسترسی به محتوایی هستند که ماهیت اصلی آن دیداری، شنیداری یا تعاملی است.

ابتدا مالک جست‌وجویی هر دارایی را تعیین کنید

یک فایل می‌تواند در چند کانال بازنشر شود، اما باید روشن باشد کدام صفحه پاسخ کامل به Intent را مالک است. صفحه مالک باید عنوان مشخص، توضیح زمینه، دارایی اصلی، شواهد، نسخه/تاریخ و اقدام بعدی داشته باشد. نسخه‌های کوتاه در شبکه اجتماعی، Embed ناشر یا صفحه دسته‌بندی باید کاربر را به آن مقصد برگردانند.

Asset ID: podcast-ep-042
User job: مقایسه هزینه جذب مشتری دو کانال
Search owner: /podcast/customer-acquisition-cost/
Primary asset: audio/mpeg + stable URL
Accessible equivalent: reviewed transcript + chapter list
Distribution: RSS, Apple, YouTube, social clips
Evidence owner: Growth Lead
Review date: 1405/06/30
Primary outcome: qualified calculator starts
Guardrail: transcript correction rate < 2%

اگر Transcript کامل در چند URL منتشر شود، ممکن است صفحات برای یک Intent رقابت کنند. بهتر است متن کامل روی صفحه مالک بماند و مشتق‌ها خلاصه، نقل‌قول کوتاه، Clip یا زاویه‌ای مستقل داشته باشند. Canonical هم جای تصمیم معماری را نمی‌گیرد؛ ابتدا محتوا و مقصدها را تفکیک کنید، سپس Canonical را با نسخه ترجیحی هم‌راستا سازید.

فرمت را از روی کار کاربر انتخاب کنید، نه جذابیت فرضی

تصویر، صدا و تعامل ذاتاً «درگیرکننده‌تر» نیستند. کاربر در مترو شاید Transcript بخواهد، هنگام رانندگی صدا، و برای مقایسه عددها جدول. فرمت نامناسب می‌تواند زمان بیشتری بگیرد و فهم را کمتر کند. برای هر موضوع بپرسید:

• کاربر باید چیزی را ببیند، بشنود، مقایسه کند یا انجام دهد؟
• آیا زمینه استفاده شامل صدای خاموش، اینترنت کند یا نمایشگر کوچک است؟
• کدام معادل برای صفحه‌خوان، موتور جست‌وجو و آرشیو لازم است؟
• هزینه تولید و نگهداری این فرمت با ارزش تصمیم متناسب است؟

برای راهبرد گسترده تولید، توزیع و ROI صوت، راهنمای برندینگ و توزیع پادکست را ببینید. این صفحه مالک جزئیات فنی کشف، معادل دسترس‌پذیر و قرارداد صفحه است.

Pipeline مشترک برای تصویر، پادکست و محتوای تعاملی

1. Intent: Query، مخاطب، Job و اقدام بعدی را ثبت کنید.
2. Production: نسخه منبع، Rights، Owner و معیار پذیرش بسازید.
3. Accessibility: Alt، Transcript، Caption، جدول یا fallback را هم‌زمان تولید کنید.
4. Metadata: عنوان، توضیح، تاریخ، زبان، Creator، License و شناسه پایدار را تکمیل کنید.
5. Delivery: URL، MIME، Cache، Range request، Responsive delivery و Player را آزمون کنید.
6. Distribution: Sitemap، Feed، پلتفرم و صفحه مالک را اعتبارسنجی کنید.
7. Measurement: کشف، مصرف، فهم و نتیجه کسب‌وکار را جدا بسنجید.
8. Refresh: تاریخ بازبینی، تغییر داده، لینک شکسته و نسخه منسوخ را پایش کنید.

سئو تصاویر: خزیدن و ایندکس قبل از Alt

راهنمای رسمی Google Images می‌گوید تصویر استاندارد در عنصر <img src> قابل‌کشف است؛ این الگو داخل <picture> نیز کار می‌کند، اما تصویر پس‌زمینه CSS مسیر مناسبی برای ایندکس تصویر نیست. بنابراین قبل از بازنویسی Alt، این کنترل‌ها را اجرا کنید:

• URL تصویر پاسخ ۲۰۰ و MIME درست بدهد و پشت Login یا Token کوتاه‌عمر نباشد.
• robots.txt، Header یا CDN درخواست خزنده را مسدود نکند.
• عنصر img یک src واقعی به‌عنوان fallback داشته باشد؛ فقط data-src سفارشی کافی نیست.
• URL فایل پایدار باشد و در هر Deploy بی‌دلیل تغییر نکند.
• اگر تصاویر روی CDN جدا هستند، مالکیت آن دامنه در Search Console بررسی شود.
• برای کتابخانه بزرگ، تصویرهای JavaScript-heavy یا CDN، Image Sitemap به کشف کمک کند.

Image Sitemap تضمین ایندکس یا رتبه نیست؛ فقط کشف URL را آسان‌تر می‌کند. صفحه میزبان نیز باید قابل‌ایندکس و مرتبط باشد.

Alt Text را با یک درخت تصمیم بنویسید

Alt برای کاربری است که تصویر را نمی‌بیند، نه محفظه تکرار کلمه کلیدی. راهنمای W3C برای متن جایگزین چهار وضعیت مفید را تفکیک می‌کند:

Alt خوب وابسته به Context است. یک عکس لپ‌تاپ در صفحه فروش ممکن است مدل و رنگ را بخواهد؛ همان عکس در مقاله‌ای درباره دورکاری شاید تزئینی باشد. اگر تصویر حامل متن ضروری است، همان اطلاعات را در HTML قابل‌انتخاب و قابل‌بزرگ‌نمایی هم ارائه کنید.

نام فایل، Caption و زمینه صفحه چه نقشی دارند؟

نام فایل توصیفی و پایدار برای مدیریت دارایی مفید است و می‌تواند سرنخ محدودی بدهد، اما اهرم اصلی رتبه نیست. برای زیرساخت‌های حساس به Encoding، نام ASCII کوتاه مانند checkout-error-rate-fa.webp عملی‌تر از رشته طولانی فارسی است. تاریخ یا Hash را فقط وقتی اضافه کنید که نسخه واقعاً تغییر می‌کند.

Caption، متن اطراف، عنوان صفحه و Heading باید توضیح دهند تصویر چرا اینجاست و چه نتیجه‌ای دارد. عبارت‌های هم‌معنا را طبیعی به کار ببرید؛ مفهوم قدیمی «LSI Keywords» را به‌عنوان چک‌لیست رسمی گوگل دنبال نکنید. اگر Caption صرفاً Alt را تکرار می‌کند، ارزشی به کاربر اضافه نکرده است.

Responsive Image و Performance را با هم طراحی کنید

فرمت جدید به‌تنهایی سرعت را تضمین نمی‌کند. ابعاد بیش‌ازنیاز، Decode سنگین، Lazy loading اشتباه و Layout shift می‌توانند تجربه را خراب کنند. برای جزئیات بیشتر، راهنمای بهینه‌سازی تصویر و ویدئو برای Performance و Accessibility را اجرا کنید.

<picture>
  <source type="image/avif" srcset="chart-640.avif 640w, chart-1280.avif 1280w">
  <source type="image/webp" srcset="chart-640.webp 640w, chart-1280.webp 1280w">
  <img src="chart-1280.jpg"
       srcset="chart-640.jpg 640w, chart-1280.jpg 1280w"
       sizes="(max-width: 720px) 100vw, 720px"
       width="1280" height="720"
       alt="مقایسه نرخ تکمیل خرید در نسخه پایه و آزمایش"
       decoding="async">
</picture>

• برای تصویر LCP، Lazy loading نگذارید؛ اولویت یا Preload را فقط پس از اندازه‌گیری اعمال کنید.
• برای تصاویر زیر Fold، Lazy loading بومی مرورگر معمولاً نقطه شروع مناسبی است.
• width و height یا نسبت تصویر مشخص کنید تا فضا رزرو شود.
• AVIF، WebP، JPEG، PNG یا SVG را با توجه به محتوا، کیفیت، پشتیبانی و حجم واقعی مقایسه کنید؛ «همه‌چیز WebP» قانون نیست.
• برای UX و اثر تجاری Performance، راهنمای سرعت سایت و Conversion را به‌کار بگیرید.

حقوق، منبع و اصالت تصویر را بخشی از کیفیت بدانید

پیش از انتشار، منبع، مجوز، Creator، محدودیت ویرایش و تاریخ دریافت را ثبت کنید. Screenshot محصول، عکس مهمان و نمودار مبتنی بر داده هرکدام قرارداد متفاوت دارند. Watermark یا ذکر منبع، مجوز استفاده را ایجاد نمی‌کند.

برای تصاویر قابل‌مجوز، Google از متادیتای Image License مانند license و acquireLicensePage پشتیبانی می‌کند. این نشانه‌گذاری برای شفافیت مجوز و Eligibility است، نه وعده رتبه بهتر. داده ساختاریافته باید با اطلاعات قابل‌مشاهده صفحه و حق واقعی شما سازگار باشد.

Preview شبکه اجتماعی با ایندکس تصویر یکی نیست

og:image، تصویر Article Schema و primaryImageOfPage می‌توانند انتخاب Preview یا فهم صفحه را پشتیبانی کنند، اما URL تصویری که در شبکه اجتماعی دیده می‌شود لزوماً همان نتیجه Google Images نیست. نسبت، Crop، حجم و Text-safe area هر کانال را جدا آزمون کنید.

دستور max-image-preview:large اجازه نمایش Preview بزرگ‌تر می‌دهد؛ انتخاب آن را تضمین نمی‌کند. برای شرایط Google Discover، راهنمای مستقل بهینه‌سازی Google Discover را ببینید و Eligibility را با تضمین نمایش اشتباه نگیرید.

سئو پادکست با یک صفحه وب و یک Feed معتبر شروع می‌شود

پلتفرم‌ها نسخه توزیعی پادکست‌اند؛ دارایی تحت کنترل شما باید Feed پایدار و صفحه اپیزود قابل‌استفاده داشته باشد. صفحه اپیزود بهتر است عنوان روشن، خلاصه، Player دسترس‌پذیر، مشخصات مهمان، Chapter، Transcript بازبینی‌شده، منابع و CTA متناسب داشته باشد.

طول Show Note را با نیاز شنونده تعیین کنید، نه عدد ثابت ۳۰۰ کلمه. اپیزود خبری کوتاه شاید به خلاصه، منبع و تاریخ نیاز داشته باشد؛ مصاحبه تخصصی به Bio، ادعاها، منابع و فصل‌بندی بیشتر. عنوان باید موضوع و تمایز را بگوید، نه انباشته‌ای از شماره، تاریخ و نام برند.

قرارداد فنی RSS پادکست

طبق الزامات رسمی Apple Podcasts، Feed عمومی RSS ۲.۰ باید Artwork و دست‌کم یک اپیزود داشته باشد. هر اپیزود به enclosure یکتا با URL، Length و Type و نیز GUID پایدار نیاز دارد؛ میزبان فایل باید HEAD و Byte-range request را پشتیبانی کند. قواعد همان پلتفرم را روز تحویل دوباره بررسی کنید.

URL و Filename فایل صوتی را ASCII، Case-consistent و پایدار نگه دارید؛ تاریخ RSS باید فرمت مورد انتظار را رعایت کند. Redirectهای زنجیره‌ای، Cookie اجباری، Hotlink protection یا CDN که Range request را خراب می‌کند می‌تواند Player را در برخی اپراتورها از کار بیندازد.

Transcript هم دسترس‌پذیری است، هم سند قابل‌ارجاع

راهنمای Transcript در W3C WAI توضیح می‌دهد متن جایگزین صوت از گفتار و صداهای غیرگفتاری لازم برای فهم تشکیل می‌شود. برای محتوای صوتی ازپیش‌ضبط‌شده، معادل متنی صرفاً ترفند SEO نیست؛ نیاز پایه دسترس‌پذیری است.

• نام گوینده، پاراگراف‌بندی و صداهای معنادار را ثبت کنید.
• Timestamp یا Chapter برای یافتن بخش‌ها بدهید؛ هر جمله را خرد نکنید.
• نام خاص، عدد، واحد پول، URL و اصطلاح انگلیسی را با صوت تطبیق دهید.
• خروجی Speech-to-text را قبل از انتشار انسانی بازبینی کنید و تاریخ اصلاح بگذارید.
• اگر نسخه خلاصه است، آن را Transcript کامل ننامید.
• در مصاحبه حساس، رضایت، حذف اطلاعات شخصی و سیاست اصلاح را روشن کنید.

Transcript نباید محتوای شنیده‌نشده را برای «غنی‌ترشدن سئو» اختراع کند. تحلیل و منابع تکمیلی را در بخش جداگانه صفحه بیاورید تا مرز سند و تفسیر روشن بماند.

Structured Data پادکست را بدون وعده Rich Result اجرا کنید

PodcastEpisode در واژگان Schema.org وجود دارد، اما در گالری جاری قابلیت‌های داده ساختاریافته Google Search نوع مستقل تضمین‌شده‌ای برای Rich Result پادکست فهرست نشده است. پس عبارت «با این Schema حتماً Rich Snippet می‌گیرید» دقیق نیست.

صفحه قابل‌مشاهده را با نوعی که واقعاً نمایندگی می‌کند—مانند WebPage یا Article در صورت انطباق—نشانه‌گذاری کنید و اطلاعات Episode را فقط اگر با محتوا و Entityهای صفحه هم‌خوان است بیفزایید. URL، تاریخ، نام، تصویر و Creator باید با نسخه قابل‌مشاهده یکی باشند. طبق سیاست‌های Google برای داده ساختاریافته، اعتبار Markup نمایش قابلیت را تضمین نمی‌کند.

توزیع پادکست را Platform-specific نگه دارید

Google Podcasts را به‌عنوان مقصد جاری برنامه توزیع ننویسید. راهنمای فعلی Google، Podcast در YouTube را بر مبنای Playlist و Episodeهای ویدئویی توضیح می‌دهد؛ Feed یا قابلیت‌های اتصال بسته به منطقه و حساب ممکن است فرق کند. برای هر پلتفرم، Eligibility، مالکیت، فرمت، Analytics و شرایط روز را همان زمان بررسی کنید.

Feed و صفحه تحت دامنه خودتان باید مرجع ماندگار باشند. حضور در Apple، YouTube/YouTube Music یا پلتفرم محلی یک Channel است، نه جایگزین مالکیت. تغییر نام سرویس، محدودیت منطقه‌ای یا مشکل پرداخت نباید آرشیو شما را از بین ببرد.

Player صوتی باید قابل‌کنترل و کم‌ریسک باشد

Player را با صفحه‌کلید، Screen reader، Mobile Safari/Chrome، سرعت پخش و Resume آزمون کنید. Autoplay صوتی نگذارید. دکمه‌ها Label قابل‌فهم، Focus visible و State روشن داشته باشند. اگر Embed ثالث کند یا مسدود شد، لینک مستقیم امن و Transcript باید باقی بماند.

فایل صوتی را یک‌جا دانلود اجباری نکنید؛ Range delivery، Cache و حجم را پایش کنید. Scriptهای Analytics و Player را از مسیر Critical rendering جدا نگه دارید. Consent و Privacy برای داده شنیدن، مهم‌تر از ثبت هر ثانیه رفتار است.

اندازه‌گیری پادکست را از تعریف Metric آغاز کنید

«Download»، «Listen» و «Completion» بین Hostها و پلتفرم‌ها تعریف یکسان ندارند. قبل از مقایسه، Window، Bot filtering، Client، Deduplication و روش شمارش را مستند کنید.

اینفوگرافیک باید یک سند قابل‌راستی‌آزمایی باشد

اینفوگرافیک خوب فقط تصویر بلند نیست. عنوان، Scope، تعریف Metric، منبع داده، دوره زمانی، روش محاسبه، Creator، تاریخ انتشار/به‌روزرسانی و محدودیت‌ها باید در HTML دیده شوند. برای داده پیچیده، جدول قابل‌کپی یا فایل CSV/PDF دسترس‌پذیر ارائه کنید.

اگر نمودار ادعا می‌کند «۷۰٪ کاربران ایرانی X را ترجیح می‌دهند»، جامعه، نمونه، تاریخ، متن سؤال و Sponsor باید مشخص باشد. داده بدون Provenance شاید Share بگیرد، اما E-E-A-T و تصمیم کاربر را تضعیف می‌کند. اصلاح داده را با Version note منتشر کنید؛ فایل قبلی را بی‌صدا جایگزین نکنید.

SVG و Canvas را معنایی و دسترس‌پذیر کنید

برای SVG، عنوان/توضیح مناسب، متن قابل‌خواندن، Contrast و Focus را آزمون کنید. اگر اطلاعات فقط با Hover ظاهر می‌شود، مسیر Touch و Keyboard هم بسازید. Canvas به‌تنهایی ساختار معنایی کافی برای صفحه‌خوان یا خزنده نمی‌دهد؛ جدول، Summary یا DOM equivalent لازم است.

Interactive chart acceptance:
- Title and question visible in HTML
- Data source, period, units and method visible
- Keyboard reaches every meaningful control
- Focus state and selected state announced
- Color is not the only carrier of meaning
- Reduced-motion path available
- HTML table or downloadable equivalent exists
- Useful default state works without JavaScript
- Share URL restores only meaningful, index-worthy state

راهنمای طراحی فراگیر و WCAG را برای Keyboard، Screen reader، Zoom، رنگ و حرکت در QA وارد کنید.

تعامل و Stateهای URL را کنترل کنید

هر Filter ترکیبی نباید یک URL قابل‌ایندکس بسازد. فقط Stateهایی را URLپذیر کنید که ارزش اشتراک، بازگشت یا Intent مستقل دارند. State پیش‌فرض باید توضیح و خروجی مفید داشته باشد؛ Error، Empty، Loading و Offline نیز طراحی شوند.

اگر محتوا با Client-side rendering می‌آید، HTML نهایی، Internal link، Title و متن معادل را در ابزارهای Crawl و مرورگر واقعی بررسی کنید. SSR یا Prerender فقط وقتی ارزش دارد که State و Cache درست باشند؛ Hydration شکسته می‌تواند نسخه‌ای ظاهراً زیبا اما غیرقابل‌تعامل تولید کند.

Embed code و Backlink را با سیاست لینک سالم طراحی کنید

کد Embed باید سبک، امن، Responsive و همراه با نسبت‌دادن دقیق منبع باشد. لینک اعتباردهی را اختیاری و با Anchor برند یا عنوان طبیعی نگه دارید. تزریق لینک Keyword-rich پنهان در Widgetهای توزیع‌شده، شرط اجباری لینک Follow یا تغییر مقصد پس از انتشار با سیاست‌های اسپم و اعتماد ناشر تعارض دارد.

Backlink نتیجه خودکار «تعاملی‌بودن» نیست. داده منحصربه‌فرد، روش شفاف، Quote دقیق، Asset قابل‌استفاده، Outreach مرتبط و امکان اصلاح شانس Citation را بالا می‌برند. License و شرایط ویرایش را کنار Download/Embed روشن کنید.

یک Content Constellation بسازید، نه نسخه‌های رقیب

یک تحقیق می‌تواند به گزارش، اینفوگرافیک، اپیزود، ویدئو و چند Clip تبدیل شود. هر مشتق باید Job مستقل یا نقش توزیعی داشته باشد و به منبع اصلی لینک دهد.

برای Video، مالک Intent تخصصی راهنمای سئو ویدئو در پلتفرم‌های مختلف است. برای برنامه Editorial، بازتوزیع و Governance، استراتژی بازاریابی محتوا را به این Constellation متصل کنید.

E-E-A-T را در خود دارایی قابل‌مشاهده کنید

• Experience: نمونه، Dataset، Screenshot یا محدودیت تجربه واقعی را نشان دهید.
• Expertise: نقش نویسنده، مهمان، تحلیلگر داده و Reviewer را مشخص کنید.
• Authoritativeness: به منبع اولیه، Method و نسخه رسمی ارجاع دهید.
• Trust: Rights، Sponsor، Conflict، استفاده از AI، تاریخ بازبینی و Correction policy را روشن کنید.

صدای باکیفیت یا گرافیک زیبا جای Citation را نمی‌گیرد. در موضوع پزشکی، مالی یا حقوقی، Scope و Reviewer متخصص مهم‌تر می‌شود؛ خلاصه تصویری نباید هشدار، استثنا یا عدم‌قطعیت منبع را حذف کند.

سنجش را بر اساس Surface تفکیک کنید

Time on page یک «سیگنال مثبت قطعی گوگل» نیست و به‌تنهایی کیفیت را اثبات نمی‌کند. زمان زیاد می‌تواند فهم عمیق یا سردرگمی باشد. رفتار، Self-report، نتیجه و Guardrail را کنار هم بگذارید و Attribution را با آزمایش یا Cohort تقویت کنید.

نسخه ایران: فارسی، RTL، شبکه و وابستگی پلتفرمی

برای مخاطب ایرانی، فقط ترجمه متن کافی نیست. این کنترل‌ها را در Definition of Done قرار دهید:

• نیم‌فاصله، ی/ک فارسی، اعداد، واحدها و جست‌وجوی شکل‌های رایج را Normalize کنید.
• RTL/BiDi را برای URL، کد، Timestamp، شماره اپیزود، درصد و نمودار آزمایش کنید.
• در نمودار مالی، ریال/تومان، مقیاس، نرخ تبدیل و تاریخ نرخ را صریح بنویسید.
• تاریخ شمسی را همراه با تاریخ ماشین‌خوان استاندارد نگه دارید.
• فونت فارسی، Glyph، Line-height، Zoom و Screenshot شبکه اجتماعی را روی Androidهای میان‌رده آزمون کنید.
• CDN، Feed، Player و فایل را روی اینترنت ثابت و چند اپراتور موبایل Probe کنید؛ فقط پاسخ دیتاسنتر کافی نیست.
• برای سرویس خارجی، دسترسی، منطقه، شرایط حساب، پرداخت و Export را همان روز مستند کنید.
• Feed، Transcript و فایل Master را تحت کنترل خود نگه دارید تا خروج یک پلتفرم آرشیو را نابود نکند.

RACI و Definition of Done

Runbook ۱: تصویر در Google Images دیده نمی‌شود

1. URL صفحه و تصویر، Status، MIME، robots و Indexability را ثبت کنید.
2. وجود img src واقعی، Render نهایی و URL CDN را بررسی کنید.
3. Context، Alt، Caption و ارتباط تصویر با Intent صفحه را بازبینی کنید.
4. Sitemap و مالکیت دامنه CDN را کنترل کنید.
5. تغییر را ثبت و با Window واقع‌بینانه پایش کنید؛ ایندکس را تضمین‌شده گزارش نکنید.

Runbook ۲: اپیزود در یک پلتفرم پخش نمی‌شود

1. Feed و Item را با Validator و XML خام بررسی کنید.
2. GUID، Enclosure، MIME، Length، HEAD و Range را تست کنید.
3. Redirect، TLS، CDN، Geo/network و User-agent behavior را مقایسه کنید.
4. Dashboard و شرط همان پلتفرم را بررسی و Timestamp Evidence ذخیره کنید.
5. صفحه مالک، Transcript و مسیر شنیدن جایگزین را فعال نگه دارید.

Runbook ۳: Transcript خودکار خطاهای جدی دارد

1. نسخه مشکل‌دار را از انتشار عمومی بردارید یا هشدار موقت بگذارید؛ صوت را حفظ کنید.
2. نام، عدد، ادعا و واژه تخصصی را بر اساس Risk اولویت دهید.
3. بازبینی انسانی و در موضوع حساس Reviewer دوم انجام دهید.
4. نسخه و Correction note منتشر کنید و Index را پس از اصلاح بررسی کنید.
5. Glossary و threshold پذیرش را به Pipeline بعدی اضافه کنید.

Runbook ۴: نمودار تعاملی بدون JavaScript یا صفحه‌کلید شکست می‌خورد

1. سؤال و داده اصلی را با HTML table/Summary قابل‌استفاده کنید.
2. Focus order، Label، selected state و Touch target را اصلاح کنید.
3. Loading/Error/Empty/Offline و reduced-motion را اضافه کنید.
4. Render، Hydration، Analytics و URL state را روی شبکه کند آزمون کنید.
5. اگر تعامل ارزش ضروری ندارد، نسخه ساده‌تر را جایگزین کنید.

Runbook ۵: ترافیک زیاد است اما نتیجه کسب‌وکار دیده نمی‌شود

1. Surface، Query، Landing، Device و کشور را Segment کنید.
2. Intent ورودی را با CTA و صفحه مالک تطبیق دهید.
3. مصرف واقعی—Play، Chapter، Table، Export—را از Pageview جدا کنید.
4. خطای Player، سرعت، Accessibility و مسیر اقدام را بررسی کنید.
5. یک Hypothesis با Guardrail و Cohort/Experiment بسازید؛ Metric نمایشی را موفقیت اعلام نکنید.

برنامه ۳۰، ۶۰ و ۹۰ روزه

روز ۱ تا ۳۰: موجودی و توقف نشت

فهرست URL، Asset، Owner، License، Alt، Transcript، Feed و Analytics را بسازید. ۲۰ صفحه با ارزش/ریسک بالاتر را Crawl و دستی QA کنید. تصاویر CSS-only، فایل‌های ۴۰۴، Feed خراب، Transcript غیرقابل‌اعتماد و نمودار بدون معادل را اول رفع کنید.

روز ۳۱ تا ۶۰: Template و کنترل انتشار

Template صفحه اپیزود، Decision tree متن جایگزین، Metadata schema، Rights register، Checklist RSS و Component نمودار دسترس‌پذیر را استاندارد کنید. Pipeline انتشار باید قبل از Go-live خطاهای Status، MIME، Range، Dimensions، Caption و Transcript review را متوقف کند.

روز ۶۱ تا ۹۰: سنجش و بهینه‌سازی Portfolio

Dashboard را بر Surface و Outcome تفکیک کنید، صفحات رقیب را ادغام یا مرزبندی کنید و سه Pilot اجرا کنید: بهبود صفحه مالک تصویر، Transcript/Chapter برای اپیزود و جدول معادل برای اینفوگرافیک. نتیجه را با Baseline، Cohort و Guardrail بسنجید؛ سپس فرمت‌های کم‌اثر و پرهزینه را کاهش دهید.

چک‌لیست انتشار محتوای غیرمتنی

• Intent، مخاطب، Search owner و CTA تعریف شده‌اند.
• URL دارایی و صفحه پایدار، عمومی و قابل‌خزش‌اند.
• Alt بر اساس نقش تصویر است؛ تصویر تزئینی Alt خالی دارد.
• تصویر پیچیده متن یا جدول معادل دارد.
• ابعاد، Responsive source، LCP/lazy strategy و CLS آزموده شده‌اند.
• Creator، منبع، License، consent و تاریخ ثبت شده‌اند.
• RSS دارای GUID/Enclosure/MIME/Length/HEAD/Range معتبر است.
• Transcript بازبینی‌شده، Chapter و منابع اپیزود موجودند.
• Structured data با محتوای قابل‌مشاهده یکسان و بدون وعده Rich Result است.
• تعامل با Keyboard، Touch، Screen reader، Zoom و reduced motion کار می‌کند.
• نسخه بدون JavaScript یا fallback اطلاعات ضروری را حفظ می‌کند.
• فارسی، RTL/BiDi، ریال/تومان، تاریخ و چند شبکه ایران QA شده‌اند.
• Metric dictionary، Owner، Guardrail و تاریخ بازبینی ثبت شده‌اند.

پرسش‌های متداول

آیا Alt تصویر باید حتماً کلمه کلیدی اصلی را داشته باشد؟

خیر. Alt باید نقش و معنای تصویر را در همان Context برای کاربری که تصویر را نمی‌بیند منتقل کند. اگر عبارت موضوعی به‌طور طبیعی برای فهم تصویر لازم است، استفاده می‌شود؛ تکرار اجباری یا Keyword stuffing به دسترس‌پذیری و کیفیت آسیب می‌زند. تصویر تزئینی معمولاً باید alt="" داشته باشد.

آیا همه تصاویر را به WebP تبدیل کنیم؟

نه به‌عنوان قانون مطلق. AVIF، WebP، JPEG، PNG و SVG برای نوع‌های مختلف محتوا مزایا و محدودیت دارند. ابعاد درست، فشرده‌سازی، Responsive delivery، fallback و رفتار LCP اغلب به‌اندازه نام فرمت مهم‌اند. خروجی را با کیفیت دیداری و حجم واقعی روی مرورگر/دستگاه هدف مقایسه کنید.

برای سئو پادکست چند کلمه Show Note لازم است؟

حد اجباری عمومی وجود ندارد. Show Note باید نیاز کاربر را پوشش دهد: خلاصه دقیق، مهمان، Chapter، منابع، Transcript و اقدام بعدی. طول از پیچیدگی اپیزود می‌آید، نه فرمول ۳۰۰ کلمه. متن کش‌دار یا تکراری ارزش ایجاد نمی‌کند.

آیا PodcastEpisode Schema باعث Rich Snippet گوگل می‌شود؟

تضمینی نیست. وجود یک Type در Schema.org با پشتیبانی Rich Result در Google Search یکسان نیست و PodcastEpisode در گالری جاری قابلیت‌های مستقل گوگل فهرست نشده است. Markup دقیق و هم‌خوان با صفحه مفید است، اما Eligibility و نمایش را نباید قطعی گزارش کرد.

برای اینفوگرافیک بلند، Alt کامل کافی است؟

خیر. Alt باید خلاصه و مقصد توضیح کامل را مشخص کند. داده، روش، منبع و نتیجه مهم را در متن یا جدول HTML نزدیک تصویر ارائه کنید تا برای صفحه‌خوان، جست‌وجو، Copy و Citation قابل‌استفاده باشد. اگر نسخه دانلودی دارید، مجوز و تاریخ نسخه را هم روشن کنید.

جمع‌بندی: دارایی را به یک سیستم قابل‌اعتماد تبدیل کنید

سئو محتوای غیرمتنی از تزریق کلیدواژه به Alt یا Transcript شروع نمی‌شود. هر دارایی به صفحه مالک، قرارداد فنی تحویل، معادل دسترس‌پذیر، منبع و Rights، متادیتای دقیق، توزیع مقاوم و سنجش متناسب با Surface نیاز دارد. وقتی این زنجیره کامل باشد، تصویر، پادکست و اینفوگرافیک هم برای کاربر ایرانی قابل‌استفاده‌تر می‌شوند و هم برای موتور و پلتفرم قابل‌فهم‌تر؛ بدون وعده‌های مبهم درباره Engagement، Backlink یا Rich Result.