افت ترافیک همیشه به معنی ضعیف‌شدن محتوا نیست. تغییر تقاضا، جابه‌جایی رتبه، مشکل ایندکس یا تغییر صفحه نتایج می‌تواند همان نمودار نزولی را بسازد. مسئله این است که قبل از بازنویسی، افت واقعی و قابل‌اقدام را از نوسان عادی جدا کنیم.
مسئله: Content Decay را دقیق تعریف کنید
برای این تحلیل، Content Decay یعنی کاهش پایدار عملکرد یک URL یا خوشه Query در یک بازه قابل‌مقایسه؛ نه صرفاً کمترشدن Click در چند روز. تعریف باید هم‌زمان Click، Impression، Position و CTR را ببیند. افت Click همراه با Impression ثابت با افت ناشی از کاهش تقاضا یک مسئله نیست.
Workflow دستی در Search Console
- در Performance، نوع Search و کشور هدف را ثابت کنید.
- بازه اخیر را با بازه قبلی هم‌طول مقایسه کنید. برای کسب‌وکار فصلی، مقایسه سال‌به‌سال معتبرتر است.
- خروجی Pages و Queries را جداگانه بگیرید و با URL به هم متصل کنید.
- URLهایی را نگه دارید که داده کافی برای تصمیم دارند؛ صفحات تازه یا کم‌نمایش را جدا کنید.
- برای هر URL بررسی کنید افت از Impression، CTR، Position یا ترکیبی از آن‌ها آمده است.
مثال عملی
فرض کنید Click یک صفحه کم شده اما Impression تقریباً ثابت است و Average Position تغییر محسوسی ندارد. این الگو ابتدا بررسی Title، Snippet و تغییرات SERP را توجیه می‌کند. اگر Impression و مجموعه Queryهای صفحه هم‌زمان کوچک شده باشند، باید تقاضای جست‌وجو، فصل و پوشش موضوع را بررسی کرد؛ بازنویسی فوری هنوز تصمیم قطعی نیست.
روش اتوماسیون
یک Pipeline ساده می‌تواند داده API سرچ کنسول را روزانه یا هفتگی دریافت کند، بازه‌ها را همسان سازد و برای هر URL چند سیگنال بسازد: درصد تغییر Click و Impression، تغییر Position، تغییر CTR، تعداد Queryهای ازدست‌رفته و تازگی آخرین ویرایش. سپس فقط موارد عبورکرده از حداقل داده وارد صف بازبینی شوند.
Threshold ثابت برای همه سایت‌ها مناسب نیست. ابتدا توزیع تاریخی تغییرات همان سایت را محاسبه کنید و آستانه را بر اساس نوسان طبیعی، فصل و اهمیت صفحه تنظیم کنید. نسخه پیشنهادی این Workflow در Content Decay Detector توضیح داده شده و منطق انتخاب آستانه در آزمایش Threshold تشخیص افت محتوا قابل پیگیری است.
ابزارها
- Google Search Console و Search Analytics API
- Google Sheets یا BigQuery برای تاریخچه و مقایسه دوره‌ای
- Looker Studio برای پایش روند، نه تصمیم‌گیری نهایی
- Crawler برای کنترل Canonical، Status Code و تغییرات داخلی
خروجی قابل‌استفاده
خروجی خوب یک فهرست بلند از صفحات قرمز نیست. برای هر URL باید علت احتمالی، سیگنال‌ها، سطح اطمینان و اقدام بعدی ثبت شود: اصلاح Snippet، ادغام با صفحه دیگر، به‌روزرسانی بخشی، بررسی فنی یا «فعلاً بدون اقدام».
نتیجه‌ای که باید انتظار داشت
این روش نتیجه تضمینی یا KPI از پیش‌تعیین‌شده ندارد. ارزش آن در اولویت‌بندی بهتر و جلوگیری از بازنویسی بی‌دلیل است. اثر واقعی فقط پس از ثبت Baseline، اجرای تغییر و مقایسه بازه معتبر مشخص می‌شود.
محدودیت‌ها
Search Console داده کامل همه Queryها را نمایش نمی‌دهد، Average Position میانگین ساده‌ای برای قضاوت نیست و تغییر SERP می‌تواند CTR را بدون تغییر کیفیت صفحه جابه‌جا کند. هم‌چنین Migration، تغییر Tracking یا Noindex شدن ناخواسته باید پیش از تحلیل محتوایی رد شود.
چه زمانی این روش مناسب نیست
برای سایت تازه، صفحه کم‌داده، رویداد خبری کوتاه‌عمر یا کسب‌وکار شدیداً فصلی که بازه مشابه ندارد، برچسب Decay قابل اتکا نیست. در این شرایط تحلیل کیفی و جمع‌آوری داده بیشتر اولویت دارد.
جمع‌بندی عملی
از یک تعریف روشن شروع کنید، بازه‌های قابل‌مقایسه بسازید، چهار سیگنال اصلی را کنار هم ببینید و خروجی را به اقدام مشخص تبدیل کنید. برای دیدن مسیرهای مکمل، به آزمایشگاه و اتوماسیون‌ها سر بزنید.
گام بعدی: اگر می‌خواهید این بررسی را تکرارپذیر کنید، ساختار ورودی و خروجی ابزار Content Decay Detector را ببینید.
