سئوی منفی چیست؟ تشخیص افت، Disavow و Runbook دفاع

افت ناگهانی کلیک ارگانیک، دیدن چندصد بک‌لینک ناشناس یا پیدا شدن صفحه‌ای کپی‌شده از محتوای شما، به‌تنهایی ثابت نمی‌کند قربانی «سئوی منفی» شده‌اید. اگر تیم با همین برچسب هیجانی شروع کند، ممکن است علت واقعی—مثل انتشار اشتباه noindex، تغییر canonical، اختلال سرور، افت تقاضا یا یک به‌روزرسانی گوگل—را دیر پیدا کند و حتی با Disavow عجولانه لینک‌های سالم را کنار بگذارد.

این راهنما برای مالک سایت، مدیر بازاریابی، متخصص سئو و تیم فنی نوشته شده است تا افت را به یک رخداد قابل‌اندازه‌گیری تبدیل کنند: دامنه اثر را مشخص کنند، خط زمانی بسازند، شواهد را حفظ کنند، میان نویز لینک و اقدام واقعی فرق بگذارند و فقط متناسب با سطح اطمینان واکنش نشان دهند. تمرکز بر سایت‌های فارسی و محدودیت‌های عملی کسب‌وکار ایرانی است؛ از ناپایداری شبکه و میزبانی تا دسترسی تیم‌ها و بازار لینک‌سازی.

سئوی منفی چیست و چه چیزی نیست؟

سئوی منفی (Negative SEO) به تلاش شخص ثالث برای آسیب‌زدن به حضور ارگانیک یک سایت گفته می‌شود؛ برای مثال نفوذ و تزریق صفحه اسپم، دست‌کاری دستورهای ایندکس، یا ساخت الگویی از لینک‌های مصنوعی با هدف ایجاد دردسر. اما «نیت مهاجم» معمولاً از روی داده‌های سئو قابل اثبات نیست. تیم شما باید روی چیزی تمرکز کند که قابل مشاهده و قابل اصلاح است: تغییر رخ‌داده، اثر آن و شواهد فنی.

هر بک‌لینک بی‌کیفیت حمله نیست و هر افت رتبه نیز از بک‌لینک نمی‌آید. وب به‌طور طبیعی پر از scraper، دامنه‌های رهاشده، صفحات تولیدشده خودکار و ابزارهایی است که URLها را جمع می‌کنند. گوگل نیز در راهنمای رسمی خود می‌گوید بیشتر سایت‌ها نیازی به ابزار Disavow ندارند و معمولاً می‌تواند تشخیص دهد به کدام لینک‌ها اعتماد کند. بنابراین اصطلاح عامه‌پسند «لینک سمی» را باید یک برچسب ابزارهای ثالث دانست، نه حکم قطعی گوگل.

پیش از بررسی حمله، افت را درست تعریف کنید

«ترافیک کم شده» شرح رخداد نیست. یک تعریف قابل پیگیری باید بازه زمانی، منبع داده، معیار و دامنه اثر داشته باشد؛ مثلاً: «از ۱۲ تا ۱۹ مرداد، کلیک وب گوگل در صفحات دسته X نسبت به هفته هم‌روز قبل ۳۴٪ کمتر شده، Impression نیز ۲۷٪ افت کرده و افت عمدتاً در موبایل و ایران دیده می‌شود.» این جمله اجازه می‌دهد اعضای سئو، توسعه و زیرساخت یک مسئله واحد را بررسی کنند.

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

کنترل صفر: آیا داده خراب است؟

• تگ Analytics یا Tag Manager پس از انتشار اخیر حذف یا دوبار اجرا نشده باشد.
• تعریف کانال، Consent، فیلتر داخلی و منطقه زمانی گزارش تغییر نکرده باشد.
• افت فقط در Analytics نباشد؛ Click و Impression سرچ کنسول را نیز مقایسه کنید.
• تاخیر پردازش یا ناهنجاری ثبت‌شده در ابزار منبع داده را بررسی کنید.
• روزهای هم‌نام هفته و بازه مشابه سال قبل را، در صورت داشتن داده کافی، کنار هم بگذارید.

دامنه اثر را قطعه‌بندی کنید

گزارش Performance را بر اساس Page، Query، Country، Device و Search appearance بشکنید. افت سراسری با افت یک قالب محصول یک مسئله نیست. برای هر قطعه، Click، Impression، CTR و Position را کنار هم ببینید؛ رتبه متوسط را به‌تنهایی معیار موفقیت نگذارید، چون ترکیب کوئری‌ها می‌تواند میانگین را جابه‌جا کند.

Incident: SEO-1405-05-12
شروع مشاهده: ۱۴۰۵/۰۵/۱۲ ساعت ۱۰:۳۰
معیار: Google Search clicks
اثر: -۳۴٪ روی /category/x/، موبایل، ایران
بدون اثر: برند، دسکتاپ، صفحات خدمات
آخرین تغییر مرتبط: انتشار قالب در ۱۴۰۵/۰۵/۱۱ ساعت ۲۱:۱۰
مالک بررسی: SEO Lead
مالک فنی: Web Lead
وضعیت: در حال جمع‌آوری شواهد

درخت تشخیص ۶۰ دقیقه اول

1. اندازه‌گیری را تأیید کنید: سرچ کنسول و Analytics/لاگ را با هم بسنجید.
2. در دسترس‌بودن را بسنجید: چند URL نماینده را از شبکه‌ها و دستگاه‌های متفاوت با پاسخ HTTP، ریدایرکت و زمان پاسخ بررسی کنید.
3. ایندکس‌پذیری را کنترل کنید: robots.txt، meta/X-Robots-Tag، canonical، status code و sitemap را ببینید.
4. پیام‌های گوگل را بخوانید: Manual Actions، Security Issues و پیام‌های Search Console را کنترل کنید.
5. خط زمانی تغییرات را تطبیق دهید: انتشار کد، افزونه، CDN/WAF، DNS، مهاجرت، محتوا و لینک داخلی.
6. الگوی افت را تحلیل کنید: سایت، پوشه، قالب، صفحه، Query، کشور و دستگاه.
7. تنها حالا شواهد بیرونی را بررسی کنید: لینک‌های تازه، حذف لینک معتبر، scraper، جعل درخواست و حمله به اعتبار برند.

اگر canonical، robots یا ایندکس مسئله است، از راهنمای تست robots.txt و راهنمای عیب‌یابی ایندکس گوگل استفاده کنید. اگر هنوز منشأ روشن نیست، چارچوب تشخیص افت رتبه و برنامه اقدام سئو کمک می‌کند فرضیه‌ها را به آزمایش‌های قابل رد تبدیل کنید.

دفتر شواهد: قبل از اصلاح، وضعیت را ثبت کنید

واکنش خوب از یک timeline تغییرناپذیر شروع می‌شود. اسکرین‌شات تنها کافی نیست؛ خروجی CSV، URL نمونه، header، نسخه فایل و زمان را با منطقه زمانی ثبت کنید. دسترسی فایل شواهد را محدود کنید و برای هر تصمیم نام تأییدکننده داشته باشید. اگر موضوع امنیتی است، پاک‌سازی عجولانه می‌تواند مسیر نفوذ را پنهان کند.

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

سناریو اول: لینک‌های اسپم و تصمیم درست درباره Disavow

گزارش لینک‌ها برای کشف سرنخ مفید است، اما بانک کامل تمام لینک‌های وب نیست. طبق مستند رسمی Links report، سرچ کنسول نمونه‌ای از لینک‌های شناخته‌شده را نشان می‌دهد، جدول‌ها می‌توانند محدود باشند و لینک حذف‌شده نیز ممکن است همچنان در گزارش بماند. پس «عدد امروز منهای دیروز» را حقیقت کامل پروفایل لینک ندانید.

لینک‌ها را با زمینه بررسی کنید، نه Toxicity Score

برای هر خوشه مشکوک، منبع و مقصد، anchor، زبان، موضوع، نحوه ایجاد، مالک احتمالی و قابلیت حذف را ثبت کنید. سیگنال‌های قابل بررسی شامل شبکه‌ای از دامنه‌های هم‌شکل، anchorهای تجاری تکراری، صفحات تولیدشده انبوه و الگوی زمانی غیرعادی است؛ ولی هیچ‌کدام به‌تنهایی «جریمه» را ثابت نمی‌کند. ابتدا بررسی کنید آیا لینک‌ها نتیجه کار آژانس قبلی، خرید لینک، رپورتاژ، همکاری یا انتقال دامنه خودتان بوده‌اند.

برای ساخت لینک سالم و تشخیص مرز آن با طرح‌های دست‌کاری، راهنمای لینک‌سازی خارجی مایندیو را بخوانید. معیار تصمیم باید منشأ و ماهیت لینک باشد، نه صرفاً DA/DR یا رنگ قرمز یک ابزار تجاری.

چه زمانی Disavow لازم است؟

راهنمای رسمی Disavow گوگل صریح است: این ابزار پیشرفته است، استفاده نادرست می‌تواند به عملکرد سایت آسیب بزند و بیشتر سایت‌ها به آن نیاز ندارند. گوگل استفاده را زمانی مطرح می‌کند که هم تعداد قابل‌توجهی لینک اسپم، مصنوعی یا کم‌کیفیت به سایت اشاره کند، و هم این لینک‌ها باعث Manual Action شده باشند یا احتمال واقعی چنین اقدامی وجود داشته باشد. دیدن چند دامنه ناشناس یا افت رتبه بدون اقدام دستی این دو شرط را برآورده نمی‌کند.

Runbook محافظه‌کارانه Disavow

1. Manual Actions را ببینید و نوع اقدام را دقیق ثبت کنید.
2. مالکیت لینک‌ها را بررسی کنید؛ لینک‌هایی که خودتان یا پیمانکار ساخته‌اید جدا شوند.
3. برای لینک ناقض سیاست، در صورت امکان درخواست حذف یا افزودن ویژگی مناسب بدهید و مکاتبه را نگه دارید.
4. از فایل Disavow فعلی نسخه بگیرید؛ آپلود فایل جدید جای فایل موجود را می‌گیرد.
5. هر URL/domain، علت، منبع شواهد، مالک تصمیم و تاریخ را در change log ثبت کنید.
6. انتخاب domain: یا URL را با نمونه‌های کافی و بازبینی نفر دوم انجام دهید.
7. دامنه‌های تحریریه‌ای، شرکای واقعی و لینک‌های ارگانیک را کورکورانه کنار نگذارید.
8. پس از ارسال، انتظار اثر آنی نداشته باشید؛ گوگل باید صفحات را دوباره بخزد و پردازش کند.

# نمونه ساختار مستندسازی؛ این فهرست توصیه واقعی برای آپلود نیست
# owner: seo@example.com | reviewed: 1405-05-20
# reason: confirmed paid-link network created by former vendor
domain:example-spam-network.test

# single URL reviewed; rest of domain not implicated
https://example.test/suspicious-page

راهنمای Manual Actions گوگل نیز تأکید می‌کند افزودن کورکورانه همه بک‌لینک‌ها به فایل Disavow، تلاش معتبر برای رفع مشکل محسوب نمی‌شود. اگر اقدام دستی دارید، رفع علت، مستندسازی حذف‌ها و درخواست بازبینی بخش اصلی فرایند است.

سناریو دوم: نفوذ، Spam Injection و تغییر noindex

اگر مهاجم به CMS، دیتابیس، DNS/CDN یا حساب مدیریتی دسترسی گرفته باشد، موضوع دیگر صرفاً «سئو» نیست؛ یک رخداد امنیتی است که اثر سئویی دارد. نشانه‌ها می‌تواند شامل صفحات دارویی/قمار، لینک پنهان، cloaking، redirect برای referrer یا user-agent خاص، تغییر sitemap، canonical به دامنه دیگر، noindex گسترده یا ساخت کاربر ناشناس باشد.

گزارش Security Issues سرچ کنسول با Manual Actions تفاوت دارد: اولی نشانه هک یا رفتار خطرناک برای کاربر را گزارش می‌کند و دومی بیشتر به نقض سیاست‌های اسپم مربوط است. فهرست URLهای نمونه در این گزارش‌ها لزوماً همه صفحات درگیر نیست؛ پاک‌سازی باید دامنه اثر را مستقل کشف کند.

Runbook مهار و بازیابی سایت هک‌شده

1. فرمانده رخداد تعیین کنید: ارتباط سئو، توسعه، زیرساخت و مدیریت از یک مسیر انجام شود.
2. شواهد را حفظ کنید: snapshot، لاگ، hash فایل‌ها، زمان‌ها و حساب‌های مشکوک را پیش از حذف ثبت کنید.
3. مهار کنید: نشست‌ها و کلیدهای در معرض خطر را با ترتیب کنترل‌شده باطل کنید؛ دسترسی مدیریتی و origin را محدود کنید.
4. دامنه را پیدا کنید: فایل، دیتابیس، cron، mu-plugin، افزونه/قالب، کاربر، DNS، CDN و سرویس ثالث را بررسی کنید.
5. ریشه را رفع کنید: بازگرداندن backup آلوده بدون بستن آسیب‌پذیری، رخداد را تکرار می‌کند.
6. SEO diff بگیرید: robots، noindex، canonical، redirect، sitemap، لینک و محتوای رندرشده را با نسخه سالم مقایسه کنید.
7. اعتبارسنجی کنید: چند URL نماینده را با user-agent و referrerهای متفاوت و URL Inspection ببینید؛ cloaking ممکن است برای مدیر پنهان باشد.
8. Review مناسب بخواهید: پس از پاک‌سازی کامل، از همان گزارش Security Issues یا Manual Actions اقدام کنید.
9. پس از رخداد پایش کنید: ورود، تغییر فایل، URL تازه، status code و وضعیت ایندکس را تا تثبیت زیر نظر بگیرید.

تست نفوذ دوره‌ای جای مانیتورینگ و patch management را نمی‌گیرد، اما برای یافتن مسیرهای قابل سوءاستفاده مفید است؛ جزئیات را در راهنمای تست نفوذ وب‌اپلیکیشن ببینید. WAF نیز باید مرحله‌ای تنظیم شود تا Googlebot واقعی یا کاربران ایرانی قربانی false positive نشوند؛ راهنمای تنظیم امن Ruleهای WAF همین فرایند را توضیح می‌دهد.

سناریو سوم: کپی محتوا و Scraping

کپی‌شدن مقاله آزاردهنده است، اما داستان «Duplicate Content Penalty خودکار» توضیح دقیقی نیست. مستند canonicalization گوگل می‌گوید وجود محتوای تکراری در وب طبیعی است و لزوماً نقض سیاست اسپم نیست؛ گوگل از میان نسخه‌های مشابه یک URL نماینده انتخاب می‌کند. مسئله عملی این است که آیا نسخه مطلوب شما کشف، خزش، ایندکس و به‌عنوان canonical انتخاب شده است.

Runbook محتوای کپی‌شده

1. URL کپی، تاریخ کشف، بخش‌های منطبق و نتیجه جست‌وجو/URL Inspection را ثبت کنید.
2. مطمئن شوید نسخه اصلی ۲۰۰، indexable، self-canonical و در sitemap است.
3. لینک‌های داخلی روشن به نسخه اصلی و اطلاعات نویسنده/به‌روزرسانی قابل بررسی داشته باشید.
4. اگر feed منشأ برداشت خودکار است، خروجی کامل/محدود، rate limit و الگوی bot را با اثر واقعی کسب‌وکار تنظیم کنید.
5. اگر صفحه کپی ناقض سیاست اسپم است، از مسیر گزارش رسمی استفاده کنید؛ اگر مسئله حق نشر است، مسیر حقوقی/میزبان را جداگانه و با مالک حقوق پیگیری کنید.
6. فقط به‌خاطر کپی‌شدن، canonical را به دامنه کپی‌کننده تغییر ندهید و وارد مقابله فنی غیرمجاز نشوید.

اگر گوگل نسخه دیگری را canonical انتخاب کرده، علت ممکن است در سیگنال‌های متناقض خود سایت باشد: ریدایرکت، canonical، sitemap و لینک داخلی باید به نسخه واحد اشاره کنند. راهنمای تجمیع URLهای تکراری گوگل قدرت نسبی این سیگنال‌ها را توضیح می‌دهد.

سناریو چهارم: جعل درخواست حذف لینک

در این سناریو شخصی با نام برند یا آژانس شما به ناشران پیام می‌دهد و حذف لینک‌های معتبر را می‌خواهد. تشخیص آن با افت ناگهانی تعداد لینک در یک ابزار ممکن نیست؛ باید منبع لینک واقعاً بررسی و ناشر تأیید کند که چه درخواستی، از چه ایمیل/دامنه‌ای و در چه زمانی دریافت کرده است.

Runbook جلوگیری و پاسخ

• یک صفحه تماس رسمی برای درخواست‌های سئو/حقوقی و دامنه‌های ایمیل مجاز منتشر کنید.
• ناشران مهم را در فهرست مالک، نوع رابطه، URL و روش تأیید نگه دارید.
• درخواست حذف باید ticket و تأیید دوم از دامنه رسمی داشته باشد؛ پیام شخصی در شبکه اجتماعی کافی نیست.
• برای لینک‌های مهم alert بگذارید، اما حذف را با بازکردن صفحه منبع یا تأیید ناشر راستی‌آزمایی کنید.
• در رخداد، header ایمیل، متن درخواست و زمان را حفظ کنید؛ سپس از کانال رسمی درخواست بازگردانی بدهید.

سناریو پنجم: DDoS، خزنده مخرب و اختلال دسترسی

DDoS یا مصرف منابع می‌تواند کاربران و crawlerها را با timeout، 5xx یا challenge نامناسب روبه‌رو کند؛ اثر سئویی یک پیامدِ مشکل availability است. راه‌حل اصلی پاک‌کردن لینک نیست: ظرفیت، CDN/WAF، حفاظت origin، rate limit، cache، مانیتورینگ و برنامه تداوم سرویس لازم است.

در ایران، رخداد را از چند مسیر شبکه و ترجیحاً از بیرون کشور نیز بسنجید؛ پاسخ خوب فقط از شبکه دفتر به معنی دسترسی جهانی نیست. برای botها بر مبنای user-agent به‌تنهایی allowlist نسازید؛ هویت crawler معتبر باید با روش توصیه‌شده همان موتور جست‌وجو و لاگ سرور تأیید شود. اگر Rule تازه‌ای منتشر شده، نرخ ۴۰۳/۴۲۹، challenge، کشور، ASN، مسیر و user-agent را قبل و بعد مقایسه کنید.

معماری و چک‌لیست پاسخ را در راهنمای پیشگیری از حمله DDoS دنبال کنید. در incident شدید، ابتدا دسترسی و امنیت را تثبیت کنید؛ درخواست بازخزش و ارزیابی رتبه بعد از سالم‌شدن پاسخ‌ها معنا دارد.

سناریو ششم: نظر جعلی و حمله به برند

نظر جعلی می‌تواند اعتماد و نرخ تبدیل را آسیب بزند، اما آن را بدون شواهد به افت رتبه ارگانیک نسبت ندهید. این رخداد بیشتر در حوزه مدیریت اعتبار، پشتیبانی و سیاست پلتفرم قرار دارد. URL، شناسه حساب، تاریخ، متن و تضاد آن با سوابق مشتری را ثبت کنید؛ از مسیر رسمی پلتفرم گزارش دهید و پاسخ عمومی کوتاه، محترمانه و بدون افشای داده شخصی بنویسید.

خرید نظر مثبت یا حمله متقابل، مسئله را به نقض سیاست و بحران اعتماد تبدیل می‌کند. KPI این جریان شامل نرخ حذف موارد اثبات‌شده، زمان پاسخ و روند امتیاز/تبدیل است؛ نه ادعای مبهم «قدرت دامنه».

ماتریس شدت و اختیار تصمیم

شدت را با «اثر × دامنه × دوام × ریسک کاربر» تعیین کنید. ده هزار لینک بی‌اثر شاید P3 باشد، اما یک تغییر noindex روی همه صفحات تراکنشی P1 است. اختیار Disavow، تغییر DNS، بازگردانی backup و ارتباط عمومی را از قبل مشخص کنید تا در بحران تصمیم‌های برگشت‌ناپذیر با یک نفر گرفته نشود.

برنامه ۲۴ ساعت، ۷ روز و ۳۰ روز

۲۴ ساعت اول: تثبیت و حذف حدس

• تعریف رخداد، owner، کانال ارتباط و log تصمیم بسازید.
• داده، دسترسی، ایندکس‌پذیری و پیام‌های Search Console را کنترل کنید.
• URLهای نماینده و cohortهای سالم/آسیب‌دیده را مشخص کنید.
• release، DNS/CDN/WAF، محتوا و رخدادهای بیرونی را روی timeline بگذارید.
• اگر نفوذ محتمل است، فرایند امنیتی را فعال و شواهد را حفظ کنید.
• تغییر بزرگ محتوا، حذف گسترده لینک یا Disavow عجولانه انجام ندهید.

هفت روز: آزمایش فرضیه و اصلاح کنترل‌شده

• برای هر فرضیه evidence for/against و آزمایش بعدی بنویسید.
• اصلاح را ابتدا روی نمونه یا با امکان rollback اجرا کنید.
• لینک‌ها را بر اساس منشأ و سیاست دسته‌بندی کنید، نه امتیاز یک ابزار.
• برای issue امنیتی پاک‌سازی کامل و review مناسب را تکمیل کنید.
• تأثیر اصلاح را روی Click/Impression، index status، status code و log پایش کنید.
• به ذی‌نفعان واقعیت، سطح اطمینان و اقدام بعدی را گزارش دهید؛ مهاجم فرضی را قطعی معرفی نکنید.

سی روز: پیشگیری و یادگیری

• Postmortem بدون سرزنش با علت ریشه‌ای، عوامل تشدیدکننده و gap کنترل‌ها بنویسید.
• تست خودکار robots/noindex/canonical/status و synthetic monitoring اضافه کنید.
• دسترسی‌های CMS، Search Console، DNS، CDN و ابزارهای لینک را بازبینی کنید.
• سیاست ارتباط با ناشر، backup فایل Disavow و تأیید دوم تغییر حساس را رسمی کنید.
• runbook را با سناریوی واقعی تمرین و contact list را به‌روز کنید.

داشبوردی که به تصمیم کمک می‌کند

داشبورد خوب «هشدار» را از «حکم» جدا می‌کند. آستانه را با baseline همان سایت و فصل تنظیم کنید؛ عدد ثابت برای همه کسب‌وکارها مفید نیست. نمودارها باید امکان شکستن بر اساس template، country و device را داشته باشند.

MTTD زمان کشف، MTTC زمان مهار و MTTR زمان بازگشت سرویس/وضعیت پایدار است. «زمان بازگشت رتبه» را تضمین نکنید؛ خزش، پردازش و ارزیابی مجدد خارج از کنترل مستقیم سایت است. هدف عملی، رفع علت و تولید شواهد سالم برای ارزیابی دوباره است.

الگوی جلسه تصمیم‌گیری ۱۵ دقیقه‌ای

1. واقعیت: چه معیاری، از چه زمانی و کجا تغییر کرده است؟
2. دامنه: چه صفحات/کاربران/کشورها سالم مانده‌اند؟
3. فرضیه‌ها: سه علت اصلی و مدرک موافق/مخالف هرکدام چیست؟
4. ریسک: آیا کاربر، داده یا درآمد در خطر فوری است؟
5. اقدام بعدی: کوچک‌ترین آزمایش یا اصلاح برگشت‌پذیر چیست؟
6. مالک و زمان: چه کسی تا چه ساعت نتیجه را گزارش می‌کند؟

این قالب جلوی دو افراط را می‌گیرد: بی‌اعتنایی به نشانه واقعی و نسبت‌دادن هر افتی به رقبا. اگر تیم بیرونی دارید، دسترسی read-only و خروجی خام بخواهید و تصمیم حساس را با نفر دوم مرور کنید.

اشتباه‌های پرهزینه در دفاع از سئوی منفی

• Disavow بر اساس فهرست Toxic: ممکن است لینک طبیعی کنار گذاشته شود و علت اصلی همچنان باقی بماند.
• خرید لینک برای «خنثی‌سازی»: ریسک سیاستی تازه ایجاد می‌کند و تشخیص را مبهم‌تر می‌سازد.
• تغییر هم‌زمان محتوا، قالب و زیرساخت: اثر هر اصلاح قابل انتساب نخواهد بود.
• اتکا به جست‌وجوی site:: برای سرنخ مفید است، اما گزارش کامل ایندکس نیست.
• بازکردن صفحه آلوده در مرورگر روزمره: ممکن است خطر امنیتی داشته باشد؛ از محیط و روش امن استفاده کنید.
• پاک‌سازی بدون رفع ریشه نفوذ: بازگشت رخداد محتمل است.
• نام‌بردن عمومی از مهاجم بدون مدرک: ریسک حقوقی و اعتباری می‌سازد.
• وعده زمان بازیابی: تیم می‌تواند اصلاح و پایش را زمان‌بندی کند، نه تصمیم سیستم جست‌وجو را.

چک‌لیست عملیاتی سئوی منفی

• رخداد با تاریخ، معیار، baseline و cohort تعریف شده است.
• سلامت Analytics/Tag Manager و تاخیر داده کنترل شده است.
• Performance بر اساس Page، Query، Device، Country و Search type شکسته شده است.
• HTTP status، redirect، robots، noindex، canonical، sitemap و render بررسی شده است.
• Manual Actions، Security Issues و پیام‌های Search Console دیده شده است.
• انتشار کد/محتوا، DNS، CDN/WAF و قطعی روی timeline قرار گرفته است.
• شواهد پیش از تغییر حفظ و دسترسی آن محدود شده است.
• لینک‌های مشکوک با منشأ، مقصد، anchor و مالک دسته‌بندی شده‌اند.
• Disavow فقط با دو شرط رسمی گوگل و بازبینی نفر دوم مطرح شده است.
• برای هک، runbook امنیتی و review گزارش مربوط اجرا شده است.
• برای scraper، سیگنال‌های canonical و مسیر سیاستی/حقوقی جدا بررسی شده است.
• هر اصلاح owner، deadline، rollback و معیار موفقیت دارد.
• Postmortem و تست پیشگیرانه پس از تثبیت انجام می‌شود.

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

آیا افزایش ناگهانی بک‌لینک یعنی حمله سئوی منفی؟

خیر. افزایش می‌تواند از scraper، کشف دیرهنگام لینک‌ها، کمپین روابط عمومی، تغییر داده ابزار یا شبکه‌ای مصنوعی بیاید. منبع، مقصد، anchor، زمان و ارتباط موضوعی را نمونه‌برداری کنید و آن را با افت و پیام‌های Search Console بسنجید. خودِ نمودار رشد، علت یا جریمه را ثابت نمی‌کند.

آیا برای لینک‌های اسپم باید فوراً Disavow ارسال کنم؟

معمولاً نه. گوگل می‌گوید بیشتر سایت‌ها به این ابزار نیاز ندارند. تنها وقتی تعداد قابل‌توجهی لینک مصنوعی/کم‌کیفیت دارید و آن‌ها باعث Manual Action شده‌اند یا احتمال واقعی چنین اقدامی وجود دارد، پس از بررسی و تلاش برای حذف، Disavow را مطرح کنید. فایل جدید نیز جای فایل موجود را می‌گیرد؛ نسخه‌برداری و peer review ضروری است.

چطور بفهمم افت رتبه از به‌روزرسانی گوگل است یا سئوی منفی؟

تاریخ و شکل افت را با cohortها، وضعیت رسمی جست‌وجو، تقاضای بازار، تغییرات سایت و گزارش‌های Search Console تطبیق دهید. افت گسترده بدون خطای فنی ممکن است با تغییر سیستم‌های رتبه‌بندی هم‌زمان باشد؛ اما هم‌زمانی هنوز اثبات علت نیست. از تغییرات رادیکال روی صفحات سالم پرهیز و فرضیه‌ها را جداگانه آزمایش کنید.

اگر سایتم هک و صفحات اسپم ساخته شد، اول چه کنم؟

رخداد امنیتی را فعال کنید: شواهد را حفظ، دسترسی را مهار، دامنه آلودگی و ریشه نفوذ را پیدا و سپس پاک‌سازی کنید. robots، noindex، canonical، redirect، sitemap و محتوای رندرشده را نیز بازبینی کنید. بعد از رفع کامل، از گزارش Security Issues یا Manual Actions—بسته به نوع هشدار—درخواست review بدهید.

آیا کپی محتوای من باعث جریمه Duplicate Content می‌شود؟

کپی‌شدن به‌خودی‌خود به معنی جریمه خودکار نیست. بررسی کنید نسخه اصلی ۲۰۰، indexable، self-canonical، در sitemap و دارای لینک داخلی روشن باشد و گوگل کدام URL را canonical می‌داند. نقض سیاست اسپم و حق نشر دو مسیر متفاوت‌اند؛ برای هرکدام از گزارش رسمی و مستندات مناسب استفاده کنید.

یادداشت تحریریه: ابزارها و رابط Search Console ممکن است تغییر کنند. این راهنما در مرداد ۱۴۰۵ با اتکا به مستندات رسمی گوگل بازبینی شده است. تصمیم Disavow، امنیتی یا حقوقی را متناسب با داده و شرایط واقعی سایت و با مسئول متخصص اتخاذ کنید.