اگر نمودار Google Discover یک روز اوج میگیرد و هفته بعد تقریباً خاموش میشود، لزوماً جریمه نشدهاید؛ و اگر هنوز گزارش Discover را در Search Console نمیبینید، لزوماً یک تنظیم فنی را جا نینداختهاید. اشتباه رایج این است که Discover را مثل رتبهگیری برای یک Keyword مدیریت کنیم: چند عنوان هیجانی، تصویر بزرگ و انتظار «ترافیک پایدار». خود Google میگوید این کانال از Search مبتنی بر Query کمپیشبینیتر است و باید مکمل آن دیده شود.
این راهنما یک Recipe تضمینی برای ورود به فید نیست؛ چنین Recipeای وجود ندارد. در عوض، یک سیستم قابلممیزی میسازد: Eligibility را از Selection و Measurement جدا میکنیم، قرارداد محتوای مناسب فید، تصویر و Preview را تعریف میکنیم، اعتماد و Page experience را با Evidence میسنجیم و برای Spike، Drop و نبود گزارش Runbook مینویسیم. Snapshot الزامات رسمی این مقاله ۱۹ مرداد ۱۴۰۵ / ۱۰ اوت ۲۰۲۶ است؛ چون مستندات و Surfaceهای Google تغییر میکنند، لینکهای رسمی هر فصل بازبینی شوند.
Google Discover چیست؟
Discover بخشی از Google Search است که محتوای مرتبط با علایق فرد را، با اتکا به سیگنالهایی مانند Web & App Activity، پیش از واردکردن Query نشان میدهد. بنابراین واحد تقاضا در Search معمولاً «نیاز بیانشده» و در Discover «علاقه استنباطشده در یک لحظه» است. این تفاوت، تضمین نمیکند که محتوای خبری همیشه بهتر از Evergreen یا موضوع عمومی همیشه بهتر از B2B باشد؛ محتوای قدیمی هم اگر برای فرد مفید و مرتبط باشد ممکن است ظاهر شود.
| Surface | محرک اصلی مشاهده | کنترل ناشر | انتظار درست |
|---|---|---|---|
| Google Search | Query کاربر | ساخت صفحه مفید برای Intent مشخص | تقاضای Keywordمحور، نسبتاً قابلمدلتر |
| Google Discover | علاقه و Context فرد | Eligibility، کیفیت Card/Page و اعتماد | فرصت مکمل و نوسانی؛ بدون تضمین نمایش |
| Google News | خبر، موضوع، مکان و ترجیح کاربر | سیاستهای News و شفافیت ناشر | Surface جدا؛ Discover معادل News نیست |
از مارس ۲۰۲۵، صفحات Publication در Google News خودکار ساخته میشوند و محتوای منطبق با سیاستها خودکار برای بررسی Eligibility در نظر گرفته میشود؛ پس ادعای قدیمی «فقط ناشران تأییدشده وارد News میشوند» دقیق نیست. جزئیات تغییر در راهنمای رسمی Publisher Center آمده است.
سه لایهای که نباید مخلوط شوند
| لایه | پرسش | خروجی قابلاثبات | برداشت غلط |
|---|---|---|---|
| Eligibility | آیا صفحه اصولاً میتواند در Discover ظاهر شود؟ | Indexed، منطبق با Policy، بدون مانع Crawl/Index | واجد شرایط = حتماً نمایش |
| Selection | آیا سیستم این Card را اکنون برای این فرد مناسب میبیند؟ | هیچ کلید یا رتبه ثابت عمومی ندارد | Schema یا Keyword، ورودی قطعی میسازد |
| Measurement | اگر نمایش شد، چه دادهای در دسترس است؟ | Impression، Click و CTR پس از Threshold | نبود Report = خطای فنی یا ممنوعیت |
طبق راهنمای رسمی Google Discover، صفحهای که در Google ایندکس شده و سیاستهای Discover را رعایت میکند خودکار Eligible است؛ Tag یا Structured Data ویژهای لازم نیست. Eligibility فقط اجازه ورود به فرآیند انتخاب است، نه وعده Impression.
قرارداد Eligibility
برای هر URL یک رکورد ساده نگه دارید. نتیجه باید Boolean یا Evidenceمحور باشد، نه «SEO خوب به نظر میرسد».
| کنترل | Evidence | وضعیت رد | مالک |
|---|---|---|---|
| HTTP نهایی | URL نهایی ۲۰۰ و بدون زنجیره Redirect | 4xx/5xx، Soft ۴۰۴ یا Loop | Engineering |
| Indexability | URL Inspection، robots meta و robots.txt | noindex یا Block ناخواسته | SEO/Engineering |
| Canonical | Canonical خودارجاع یا تصمیم مستند | Credit به URL دیگری منتقل میشود | SEO |
| Policy | چکلیست موضوع، Preview، Ads و Sponsorship | نقض Search/Spam/Discover policy | Editor/Legal |
| Preview | Headline، تصویر منتخب و max-image-preview | تصویر نامرتبط یا Preview گمراهکننده | Editor/Design |
| Transparency | Byline، تاریخ، Author/About و Contact | منشأ محتوا یا منفعت مالی مبهم | Publisher |
برای Crawl، Canonical، Sitemap و Indexing سراسری از چکلیست ممیزی کامل سئو استفاده کنید؛ این مقاله فقط Boundary مربوط به Discover را مالک است.
محتوای مناسب فید؛ Trend chasing نیست
Google محتوای بهموقع، روایت خوب یا بینش منحصربهفرد را توصیه میکند. این توصیه با «هر ترندی را سریع بازنویسی کن» فرق دارد. اگر سایت درباره زیرساخت ابری است، پوشش یک ترند سینمایی صرفاً برای Impression، Audience fit و Purpose سایت را مخدوش میکند. Topic باید همزمان سه شرط داشته باشد:
- Audience fit: مخاطب موجود یا مطلوب سایت واقعاً به آن اهمیت میدهد.
- Distinct value: تجربه، داده، تحلیل، تصویر یا روایت تازهای دارید.
- Timing: اکنون دلیل معناداری برای دیدن آن وجود دارد؛ یا Evergreen بودنش برای علاقه پایدار ارزش دارد.
| نوع | نمونه برای کسبوکار ایرانی | Evidence تمایز | ریسک |
|---|---|---|---|
| Timely explainer | اثر یک تغییر رسمی درگاه یا الگوریتم بر فروشگاه | منبع رسمی + سناریوی عملی | انتشار عجولانه و خطای واقعیت |
| Original analysis | تحلیل داده ناشناسشده RUM یا پشتیبانی | Method، Sample و محدودیت | تعمیم نمونه کوچک |
| First-hand story | مهاجرت، شکست، Recovery و نتیجه واقعی تیم | Timeline، Screenshot و Decision log | Case study تبلیغاتی پنهان |
| Evergreen utility | Checklist یا Calculator ماندگار | خروجی قابلاستفاده و Refresh owner | راهنمای عمومی بدون تمایز |
معماری Topic، توزیع و بازنشر را در راهنمای استراتژی بازاریابی محتوا نگه دارید. Discover یک Distribution opportunity است، نه کل استراتژی محتوا.
People-first و E‑E‑A‑T را به Evidence تبدیل کنید
E‑E‑A‑T یک «امتیاز» یا یک Meta tag نیست و خود Google آن را فاکتور منفرد رتبهبندی معرفی نمیکند. Trust مهمترین جزء این چارچوب مفهومی است. سؤال عملی این نیست که چند بار نام نویسنده را تکرار کنیم؛ سؤال این است که خواننده چگونه ادعا را ارزیابی کند.
| ادعا | Evidence مناسب | نشانه ضعیف |
|---|---|---|
| «این روش را اجرا کردیم» | Scope، زمان، محیط، قبل/بعد و محدودیت | داستان بیتاریخ و بدون جزئیات |
| «طبق منبع رسمی» | لینک مستقیم، تاریخ Snapshot و تفسیر محدود | «تحقیقات نشان میدهد» بدون منبع |
| «نویسنده صلاحیت دارد» | Byline متصل به صفحه Author واقعی | نام عمومی «تیم تحریریه» بدون فرآیند |
| «محتوا بهروز است» | Modified date همراه Change note واقعی | تغییر تاریخ بدون تغییر معنادار |
| «بررسی مستقل است» | Disclosure مالکیت، Affiliate یا Sponsorship | تبلیغ در لباس Editorial |
راهنمای رسمی محتوای مفید روی Who، How و Why تأکید دارد. برای پیادهسازی Author، Citation، Review، Conflict و Correction به سیستم اعتماد و E‑E‑A‑T محتوا رجوع کنید.
Headline contract؛ جذاب، دقیق و قابلتحویل
Headline باید ماهیت مطلب را منتقل کند. Curiosity gap وقتی سالم است که اطلاعات اصلی را پنهان یا واقعیت را بزرگنمایی نکند. عنوان، تصویر و Lead یک Contract واحدند: هر وعده Card باید در بالای صفحه تحویل داده شود.
| نسخه پرریسک | مسئله | نسخه قابلدفاع |
|---|---|---|
| «این راز فروش شما را منفجر میکند» | اغراق، Outcome بدون Scope | «سه تغییر Checkout که در تست ما خطای پرداخت را کم کرد» |
| «باورنکردنی؛ همه اشتباه میکنند» | Outrage bait و Claim مبهم | «پنج خطای رایج Canonical و روش تشخیص هرکدام» |
| «نتیجه را هرگز حدس نمیزنید» | حذف اطلاعات لازم از Preview | «چرا LCP خوب بود اما Conversion افت کرد؛ گزارش یک Incident» |
قبل از انتشار، Editor سه تطابق را امضا کند: Headline↔Lead، Image↔Story و Snippet↔Page. اگر عدد، تاریخ، نقلقول یا نتیجهای در Headline است، Source و Context آن در متن نزدیک باشد. چکهای عمومی Title/Heading/Intent در چکلیست سئو داخلی صفحه توضیح داده شدهاند.
تصویر Discover؛ مشخصات فعلی
در Snapshot این راهنما، Google برای تصاویر بزرگ Discover مشخصات زیر را توصیه میکند: حداقل عرض ۱۲۰۰ پیکسل، وضوح بیش از ۳۰۰٬۰۰۰ پیکسل کل، نسبت پیشنهادی ۱۶:۹ و اجازه پیشنمایش بزرگ با max-image-preview:large یا AMP. عدد عرض بهتنهایی کافی نیست؛ تصویر ۱۲۰۰×۲۰۰ فقط ۲۴۰هزار پیکسل دارد.
| کنترل | قبول | رد/هشدار |
|---|---|---|
| Dimensions | مثلاً ۱۲۸۰×۷۲۰؛ بیش از 300k پیکسل | Thumbnail کوچک Upscaleشده |
| Crop | سوژه در Safe area افقی ۱۶:۹ | چهره/محصول در Crop حذف میشود |
| Relevance | نماینده همان Story | Logo عمومی یا Stock نامرتبط |
| Text | تصویر بدون متن سنگین | Poster با نوشته ریز فارسی |
| Rights | مالکیت/مجوز و Credit ثبتشده | تصویر کپیشده از شبکه اجتماعی |
| Preferred image | og:image یا Image در Schema دقیق | چند URL متناقض یا فایل Blockشده |
انتخاب Preview کاملاً خودکار است؛ Metadata فقط میتواند تصویر ترجیحی را مشخص کند. راهنمای بهروز Google Image SEO، primaryImageOfPage، Image در Entity اصلی و og:image را توضیح میدهد. Alt را برای Accessibility و معنی تصویر دقیق بنویسید؛ آن را با Keyword پر نکنید و تضمین انتخاب Preview ندانید. برای Format، Responsive image، Lazy loading، CLS و Alt از راهنمای تصویر و ویدئو وب استفاده کنید.
Preview policy در کد
<meta name="robots" content="index,follow,max-image-preview:large">
<meta property="og:image" content="https://example.com/images/story-1280x720.webp">
<meta property="og:image:width" content="1280">
<meta property="og:image:height" content="720">این نمونه فقط Intent را نشان میدهد. اگر افزونه SEO همین Robots یا OG را میسازد، Tag تکراری اضافه نکنید. HTML عمومی و Header نهایی را بررسی کنید؛ تنظیم پنل ادمین Evidence کافی نیست. تصویر باید برای Googlebot قابل Fetch، دارای MIME درست و پاسخ ۲۰۰ باشد.
Structured Data؛ مفید، اما نه بلیت ورود
Discover به Schema ویژه نیاز ندارد. Article/BlogPosting دقیق میتواند فهم Page و تصویر/نویسنده را بهتر کند، اما Eligibility تضمینشده یا Selection قطعی نمیسازد. Markup باید با محتوای قابلمشاهده منطبق باشد.
| Field | قرارداد | خطای رایج |
|---|---|---|
headline | هممعنا با عنوان قابلمشاهده | عنوان هیجانی متفاوت برای Bot |
image | تصویر نماینده، قابل Fetch و با وضوح بالا | Logo یا تصویر حذفشده |
author | Person/Organization واقعی با URL | Author جعلی یا Publisher بهجای Author |
datePublished | تاریخ انتشار واقعی با timezone | بازنویسی تاریخ در هر Crawl |
dateModified | فقط پس از تغییر معنادار | Freshness نمایشی |
مستند رسمی Article structured data میگوید Property اجباری برای این Feature وجود ندارد، اما Propertyهای قابلاعمال را دقیق وارد و با Rich Results Test و URL Inspection بررسی کنید.
Page experience؛ سیستم است، نه یک نمره
Discover صفحه کند، پر از Interstitial یا آگهی مزاحم را برای انسان بهتر نمیکند، اما امتیاز سبز Lighthouse هم تضمین نمایش نیست. Google میگوید Signal واحدی به نام Page experience وجود ندارد. کیفیت تجربه را بهصورت مجموعه کنترل کنید:
- Core Web Vitals میدانی روی Mobile و Template واقعی؛ نه فقط یک تست Lab.
- HTTPS، نمایش درست در Mobile و Main content قابلتشخیص.
- نبود Interstitial مزاحم پیش از دسترسی به محتوای اصلی.
- نسبت معقول Ads/Promotion به Editorial content.
- Navigation، Font فارسی، RTL، Tap target و خوانایی در شبکه ضعیف.
راهنمای رسمی Page experience نیز هشدار میدهد نمره خوب Core Web Vitals بهتنهایی رتبه برتر را تضمین نمیکند. سنجش LCP/INP/CLS با RUM و تفکیک Device/Network در راهنمای Core Web Vitals آمده است.
Ads، Sponsorship و Affiliate
در سیاست Discover، تبلیغ و مواد تبلیغاتی پولی نباید بر محتوای صفحه غلبه کند و Sponsorship یا منفعت مادی نباید در لباس Editorial پنهان شود. یک Disclosure کوچک در Footer برای Review اسپانسری کافی نیست اگر خواننده پیش از Claim اصلی آن را نمیبیند.
| سناریو | Disclosure لازم | کنترل تجربه |
|---|---|---|
| مقاله اسپانسری | برچسب روشن در بالای مقاله + Sponsor | Editorial/Ad visual distinction |
| Affiliate review | نوع منفعت و Method انتخاب | گزینههای بدیل و محدودیت |
| محصول متعلق به Publisher | رابطه مالکیت | Claim قابلاثبات و مقایسه منصفانه |
| نمونه رایگان | حمایت مادی | حق نقد و Method مستقل |
فهرست کامل محتوای خطرناک، گمراهکننده، دستکاریشده، پزشکی، خشونتآمیز و سایر محدودیتها را از سیاست رسمی محتوای Discover بخوانید. برای موضوعات حساس، Editor و متخصص/مشاور مرتبط باید پیش از انتشار Sign-off دهند.
تقویم انتشار بر اساس Opportunity
تقویم را از «روزانه سه مقاله» شروع نکنید. یک Opportunity record بسازید:
| فیلد | نمونه | Gate |
|---|---|---|
| Audience | مدیر فروشگاه ایرانی با افت پرداخت | با Purpose سایت همخوان است؟ |
| Trigger | تغییر رسمی یا الگوی تازه Support | Source و Timestamp داریم؟ |
| Angle | اثر عملی + Checklist | فراتر از خلاصه رقباست؟ |
| Evidence | Log ناشناسشده، آزمایش، Interview | قابل بازبینی است؟ |
| Visual | نمودار یا تصویر اختصاصی ۱۶:۹ | حقوق و Crop تأیید شده؟ |
| Expiry | ۷ روز یا Evergreen | Refresh/Archive owner دارد؟ |
برای هر Story یک Owner، Deadline و Kill rule تعیین کنید. اگر Source تأیید نشد یا زاویه تمایزی نداشت، انتشار را لغو کنید؛ هزینه فرصت محتوای بیارزش بیشتر از ازدستدادن یک Trend است.
Workflow انتشار Discover-ready
- Opportunity brief: Audience، Trigger، Unique value و Expiry.
- Evidence plan: Primary source، داده دستاول، Reviewer و Conflict.
- Story draft: Lead سریع، Context، Evidence، Limitation و Action.
- Card contract: Headline، Description، Image و وعده واحد.
- Policy gate: موضوع حساس، Sponsorship، Ads و Preview.
- Technical gate: ۲۰۰، Indexable، Canonical، Mobile، Image fetch و Schema consistency.
- Publish evidence: URL، Screenshot، HTML snapshot و Timestamp.
- Observe: Search Console، RUM، Analytics و Incident annotation.
- Refresh/retire: بر اساس تغییر واقعی، نه دستکاری تاریخ.
نوشتن Query-first برای Search همچنان ارزش دارد و با Discover تضاد ندارد. Boundary و Refresh محتوای Searchمحور را در راهنمای محتوای سئو شده مدیریت کنید.
گزارش Discover در Search Console
گزارش فقط وقتی ظاهر میشود که Property به حداقل نامشخصی از Impression برسد. در مستند فعلی، تا ۱۶ ماه داده را نشان میدهد و Discover در Surfaceهای مختلف، از جمله Chrome، ردیابی میشود. نبودن Menu، عدد صفر صریح یا اثبات Policy violation نیست.
| Metric | تعریف عملی | نباید با چه چیزی اشتباه شود |
|---|---|---|
| Impression | Item در View اسکرول شده است | Reach تخمینی یا Pageview |
| Click | کلیک روی Item | Share یا Interaction دیگر |
| CTR | Click ÷ Impression | کیفیت محتوا بهتنهایی |
| Page | داده به Canonical URL نسبت داده میشود | همیشه همان Landing URL ظاهری |
| Total | شامل Rowهای زیر Threshold نیز میشود | جمع ساده جدول قابلمشاهده |
جزئیات Threshold، Dimensionهای Page/Country/Appearance/Day و تعریف Metric در مستند رسمی Discover Performance report است. داده Search Console را با Analytics یکی ندانید: تعریف Click، Consent، Redirect، Ad blocker، timezone و Sessionization متفاوت است.
Measurement contract
| فیلد | تصمیم پیشنهادی |
|---|---|
| Source of truth | GSC برای Impression/Click/CTR؛ Analytics برای رفتار پس از Landing |
| Grain | Canonical page × country × day؛ فقط در صورت کف داده |
| Timezone | Timezone هر منبع ثبت؛ Join روزانه کور ممنوع |
| Window | ۲۸ روز در برابر ۲۸ روز + مقایسه Year-over-year در موضوع فصلی |
| Latency | Watermark و آخرین روز کامل؛ داده تازه Preliminary فرض شود |
| Annotations | Publish، Refresh، Migration، Outage، Core update و کمپین |
| Business outcome | Signup/Lead/Revenue با Attribution محدود و گزارششده |
برای اتصال GSC، Analytics، Warehouse، Consent و Attribution از معماری تحلیل دادههای بازاریابی استفاده کنید. Discover Click را Conversion علّی ننامید؛ برای Incrementality به Holdout یا طراحی آزمایش مناسب نیاز دارید.
Dashboard تصمیم، نه Vanity
| لایه | شاخص | تصمیم |
|---|---|---|
| Eligibility health | Indexable، Canonical، image fetch، policy/manual action | Fix مانع یا Escalate |
| Distribution | Eligible pages، pages with impression، impression concentration | ریسک وابستگی به چند URL |
| Card | CTR با Impression band و کشور | Review تطابق Headline/Image |
| Experience | LCP/INP/CLS، engagement و error روی Discover landing | رفع Template/Network issue |
| Outcome | Signup/Lead/Revenue و quality | ارزش واقعی کانال |
| Risk | Share ترافیک Discover، Sponsor ratio، stale claims | تنوع و Governance |
Median CTR همه URLها بدون Impression band گمراهکننده است؛ Page با ده Impression را کنار Page با یک میلیون Impression نگذارید. سهم Top ۱/۵/۱۰ URL را نشان دهید تا Fragility پنهان نماند.
Runbook: گزارش Discover اصلاً دیده نمیشود
- تأیید کنید Property درست و دسترسی Search Console صحیح است.
- بدانید Report فقط پس از عبور از حداقل Impression ظاهر میشود؛ Threshold عمومی ثابت ندارد.
- Indexability چند URL نماینده را با URL Inspection، Canonical و HTML عمومی بررسی کنید.
- Security & Manual Actions و پیامهای Search Console را بخوانید.
- Robots، Image fetch،
max-image-previewو Policy را ممیزی کنید. - اگر مانع قطعی نیست، «باید صبر کرد» را با «نمایش حتماً میآید» اشتباه نگیرید؛ Eligibility ضمانت Selection نیست.
Runbook: افت ناگهانی Impression
| فرضیه | Evidence | اقدام |
|---|---|---|
| تغییر علاقه/تقاضا | افت موضوعی، فصل، Trend و Queryهای مرتبط | Forecast را اصلاح؛ کیفیت را بیدلیل دستکاری نکنید |
| تغییر نوع محتوا/سیستم | افت چند Site/Topic همزمان و Search update | Annotation و انتظار برای داده کافی |
| خطای فنی | noindex، Canonical drift، 5xx، image ۴۰۳، Template change | Rollback/Fix و Recrawl |
| Policy/Manual action | پیام رسمی در Search Console | Scope، Remediation و Reconsideration طبق دستور |
| Logging anomaly | صفحه Data anomalies رسمی | داده را Mark و تصمیم بزرگ را عقب بیندازید |
| Concentration | بیشتر افت از یک URL پرحجم | تحلیل URL/Topic، نه بازطراحی کل سایت |
یک تغییر همزمان Title، Image، Template و Content، علت افت/بهبود را مبهم میکند. ابتدا Timeline و Exposure را بسازید، سپس کمترین تغییر قابلبازگشت را اعمال کنید.
Runbook: Impression ثابت، CTR افت کرده
- CTR را در همان Country، Appearance، بازه Impression و Topic مقایسه کنید.
- Card واقعی را اگر در دسترس است Capture کنید؛ Google ممکن است Image/Title نمایشدادهشده را انتخاب کند.
- Headline↔Lead و Image↔Story را دوباره بررسی کنید؛ Clickbait راهحل نیست.
- رقابت رویدادی و تغییر Freshness را بهعنوان Confounder ثبت کنید.
- اگر Variant میسازید، یک متغیر را تغییر دهید و از نتیجه یک URL ادعای علّی نسازید.
Freshness؛ تاریخ را دستکاری نکنید
بهروزرسانی واقعی یعنی Claim، داده، راهکار یا نتیجهای تغییر کرده است. تغییر چند واژه و جلوکشیدن dateModified اعتماد را بالا نمیبرد. یک Change note کوتاه نگه دارید:
| فیلد | نمونه |
|---|---|
| Changed | مشخصات تصویر Discover با شرط بیش از 300k پیکسل اصلاح شد |
| Why | مستند رسمی Google تغییر کرده است |
| Evidence | URL منبع + Snapshot date |
| Reviewer | SEO owner / Editor |
| Next review | سه ماه بعد یا هنگام Update رسمی |
ملاحظات ایران و محتوای فارسی
Surface و حجم Discover میتواند با کشور، زبان، حساب، Activity، دستگاه و نسخه App/Chrome متفاوت باشد. از مشاهده یک کاربر در تهران نتیجه نگیرید «برای همه کاربران ایرانی فعال/غیرفعال است». تست را روی Matrix واقعی انجام دهید:
| محور | نمونه تست | Evidence |
|---|---|---|
| Device | Android کمرده/میانرده و نمایشگرهای مختلف | Screenshot و RUM |
| Surface | Google app و Chrome surface در صورت دسترسی | App/browser version |
| Network | اپراتور، Wi‑Fi، latency و packet loss | زمان و Provider |
| Locale | fa-IR، عدد فارسی/لاتین، RTL و BiDi | Visual regression |
| Date | شمسی قابلخواندن + ISO/Timezone در Machine data | HTML و Schema |
| Image | WebP/JPEG fallback، Crop و Font داخل تصویر | Fetch ۲۰۰ و Decode time |
اگر منبع یا ابزار خارجی برای تیم در دسترس نیست، Eligibility، هزینه ارزی، روش پرداخت، Export داده و جایگزین را از ابتدا ثبت کنید. ادعای «میلیونها کاربر جدید» برای بازار ایران بدون داده Property خودتان تصمیم بودجهای قابلدفاعی نیست.
RACI عملیات Discover
| کار | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Opportunity و Story | Writer/Editor | Content lead | Subject expert | SEO |
| Headline/Image contract | Editor/Designer | Content lead | Legal/Brand | Analytics |
| Technical eligibility | SEO/Engineer | Engineering lead | Editor | Publisher |
| Policy و Disclosure | Editor | Publisher | Legal/Compliance | Commercial |
| Measurement | Analyst | Growth lead | SEO/Engineering | Editorial |
| Incident/Drop | SEO owner | Publisher | Editor/Engineer/Analyst | Leadership |
برنامه ۹۰روزه
روز ۱ تا ۳۰: Baseline و Eligibility
- فهرست Templateها، URLهای نماینده و وضعیت Index/Canonical بسازید.
- Policy، Transparency، Sponsor و Author/About/Contact را ممیزی کنید.
- تصاویر را برای Dimensions، Pixels، Crop، Rights، OG و Fetch بررسی کنید.
- گزارش GSC و Threshold/absence را مستند و Baseline ۱۶ماهه در صورت دسترسی Export کنید.
روز ۳۱ تا ۶۰: Pilot editorial
- ۱۰ Opportunity همراستا با Audience بسازید و فقط ۳ تا ۵ مورد Evidenceدار را انتخاب کنید.
- Headline/Image/Lead contract، Policy gate و Publish evidence را اجرا کنید.
- RUM و Analytics روی Landingهای Discover را از نظر Source/Consent/Timezone تست کنید.
- دو Drill برای image failure و canonical drift انجام دهید.
روز ۶۱ تا ۹۰: Observe و Govern
- Dashboard Eligibility/Distribution/Card/Experience/Outcome/Risk بسازید.
- Concentration، Spike/Drop و Difference میان GSC و Analytics را توضیح دهید.
- Runbookهای missing report، impression drop و CTR drop را تمرین کنید.
- Cadence ماهانه Editorial و فصلی Policy/Documentation review را تصویب کنید.
اشتباههای پرتکرار
| اشتباه | چرا نادرست است | اصلاح |
|---|---|---|
| Discover را کانال پایدار وعده میدهیم | خود Surface ذاتاً نوسانیتر است | Supplemental channel و Range forecast |
| Schema را شرط ورود میدانیم | Schema ویژه لازم نیست | Accuracy برای فهم صفحه، نه تضمین |
| E‑E‑A‑T را امتیاز مینامیم | فاکتور منفرد نیست | Evidence و Trust system |
| فقط عرض ۱۲۰۰ را چک میکنیم | Pixel count و Ratio هم مهماند | >300k، ۱۶:۹ و Crop test |
| نبود Report را Penalty میدانیم | Minimum impression threshold دارد | Eligibility audit، نه نتیجهگیری شتابزده |
| تاریخ را برای Freshness عوض میکنیم | Evidence تغییر ندارد | Meaningful update + Change note |
| CTR را کیفیت محتوا میدانیم | Topic، Country، Card و Context دخیلاند | Segment و Outcome مشترک |
| ترند نامرتبط تولید میکنیم | Audience/Purpose و اعتماد را فرسوده میکند | Audience fit + unique evidence gate |
چکلیست پیش از انتشار
- URL نهایی ۲۰۰، Indexable و Canonical تصمیمگرفتهشده است.
- Headline، Image، Snippet و Lead یک وعده واحد را تحویل میدهند.
- Byline، تاریخ واقعی، Author/Publisher/About و Contact قابلدسترسیاند.
- Source، Method، Limitation و Conflict/Sponsorship شفافاند.
- تصویر حداقل 1200px، بیش از 300k پیکسل، مناسب ۱۶:۹ و دارای حقوق روشن است.
max-image-preview:largeو تصویر ترجیحی در HTML عمومی درستاند.- Article markup با متن قابلمشاهده سازگار است؛ Tag تکراری نداریم.
- Mobile، CWV میدانی، Ads و Interstitial کنترل شدهاند.
- Policy gate و موضوع حساس توسط Owner مناسب تأیید شدهاند.
- Publish snapshot، Annotation، Measurement window و Refresh owner ثبت شدهاند.
پرسشهای متداول
چگونه وارد گوگل دیسکاور شویم؟
فرآیند ثبت یا Tag ویژهای وجود ندارد. اگر صفحه در Google ایندکس شده و سیاستهای Discover را رعایت کند خودکار واجد شرایط است؛ اما نمایش تضمین نمیشود. روی محتوای People-first، Preview صادقانه، تصویر مناسب، شفافیت ناشر و تجربه صفحه کار کنید و Eligibility را با Evidence بسنجید.
آیا Structured Data برای Google Discover لازم است؟
خیر؛ Google صریحاً میگوید Structured Data ویژهای برای Eligibility لازم نیست. Article/BlogPosting دقیق و og:image میتوانند به فهم صفحه و مشخصکردن تصویر ترجیحی کمک کنند، ولی بلیت ورود یا تضمین Impression نیستند.
تصویر مناسب Discover چه ابعادی دارد؟
در مستند فعلی، حداقل عرض ۱۲۰۰ پیکسل، بیش از ۳۰۰هزار پیکسل کل، نسبت پیشنهادی ۱۶:۹ و اجازه max-image-preview:large توصیه شده است. تصویر باید مرتبط، باکیفیت، قابل Fetch، دارای حق استفاده و بدون متن سنگین باشد.
چرا گزارش Discover در Search Console ندارم؟
این گزارش فقط پس از رسیدن Property به حداقل نامشخصی از Impression ظاهر میشود. ابتدا Property، Indexability، Canonical، Policy، Manual action، Robots و Image fetch را بررسی کنید. اگر مانع قطعی پیدا نشد، نبود گزارش را جریمه یا وعده نمایش آینده تلقی نکنید.
چرا ترافیک Discover ناگهان افت کرد؟
تغییر علاقه کاربران، نوع محتوای منتخب، Updateهای Search، Seasonality، Concentration روی چند URL، خطای فنی، Policy action یا حتی Logging anomaly میتواند دخیل باشد. Timeline و Segment بسازید، Search Console و HTML عمومی را بررسی و پیش از تغییر گسترده علتهای قابلاثبات را جدا کنید.
جمعبندی: Discover را به سیستم فرصت و ریسک تبدیل کنید
موفقیت در Discover با «ترفند ورود» مدیریت نمیشود. Eligibility حداقل است، Selection در اختیار سیستم و علایق فرد است و Measurement هم پس از Threshold و با محدودیت عرضه میشود. مزیت واقعی ناشر از یک Operating system میآید: Audience fit، Evidence منحصربهفرد، Card صادقانه، تصویر درست، اعتماد قابلممیزی، صفحه سالم، داده با Contract و Runbook نوسان.
این هفته بهجای تولید ده عنوان هیجانی، سه کار انجام دهید: یک URL را از HTTP تا Canonical/Image/Policy ممیزی کنید، یک Opportunity با Evidence دستاول بسازید و Dashboard را طوری اصلاح کنید که سهم Discover، Concentration و Outcome کسبوکار را کنار هم نشان دهد. اگر نمایش نیامد، دارایی مفید برای مخاطب و Search ساختهاید؛ اگر آمد، برای فرصت و نوسانش آمادهاید.
