«جریمه امنیتی گوگل» نام دقیقی نیست، اما چیزی که کاربران فارسی‌زبان با آن جست‌وجو می‌کنند کاملاً واقعی است: صفحه‌ی هشدار قرمز مرورگر، افت ناگهانی ترافیک، و پیامی در Search Console که میگوید سایت شما محتوای مخرب دارد. این وضعیت با جریمه‌های سئو یکی نیست — سازوکار، گزارش و مسیر رفعش کاملاً جداست. این مقاله توضیح می‌دهد Google Safe Browsing چه چیزی را علامت می‌زند، گزارش Security Issues را چطور بخوانید، درخواست بازبینی چگونه کار میکند، چرا رد میشود، و پس از رفع، بازگشت سئو چه شکلی است.
در یک نگاه
- هشدار امنیتی گوگل نتیجه‌ی Safe Browsing است و در کروم، فایرفاکس، سافاری و اج هم‌زمان دیده میشود — چون همه از همان داده تغذیه می‌شوند.
- دسته‌های اصلی: بدافزار، صفحات فریب‌دهنده و مهندسی اجتماعی، دانلودهای مخرب و دانلودهای غیرمعمول.
- درخواست بازبینی بعد از پاکسازی کامل و بستن نقطهی ورود معنا دارد؛ زودتر از آن، شکست تقریباً قطعی است.
- زمان بازبینی ثابت و تضمین‌شده نیست و بسته به دستهی مشکل و شرایط متفاوت است؛ به هیچ عدد قطعی‌ای تکیه نکنید.
- بازیابی سئو مرحلهی جداگانه‌ای است: رفع هشدار، رتبه‌ها را فوراً برنمی‌گرداند.
Safe Browsing چیست و «بلاک شدن سایت در گوگل» یعنی چه
Google Safe Browsing سرویسی است که فهرستی از منابع ناامن نگه می‌دارد و مرورگرها و برنامه‌ها پیش از بارگذاری یک آدرس، آن را در برابر این فهرست بررسی می‌کنند. وقتی دامنه یا یک مسیر از سایت شما در این فهرست قرار بگیرد، مرورگر پیش از نمایش صفحه یک هشدار تمام‌صفحه نشان می‌دهد.
سه نکته که تصویر را روشن میکند:
- این یک «جریمه» به معنای سئو نیست. جریمهی سئو (اقدام دستی یا اثر الگوریتمی) درباره‌ی کیفیت و انطباق محتواست و در بخش «Manual actions» گزارش میشود. هشدار امنیتی درباره‌ی خطر برای کاربر است و در بخش «Security issues» گزارش میشود. مسیر رفع این دو کاملاً متفاوت است.
- اثرش فراتر از گوگل است. فایرفاکس، سافاری و اج نیز از Safe Browsing (یا سرویس‌های مشابه) استفاده می‌کنند، بنابراین هشدار در عمل در بیشتر مرورگرها ظاهر میشود. برخی ارائه‌دهندگان ایمیل و فیلترهای شبکه هم از همین داده استفاده می‌کنند، پس لینک‌های شما در ایمیل هم مسدود میشود.
- ممکن است فقط بخشی از سایت علامت خورده باشد. علامت‌گذاری می‌تواند در سطح URL، مسیر، یا کل دامنه باشد. این یکی از دلایلی است که صاحب سایت هشدار را نمی‌بیند اما کاربران می‌بینند.
«ترافیکم افتاده، پس گوگل من را جریمهی سئو کرده.» قبل از هر فرضی، بخش Security issues در Search Console را ببینید. افت ناگهانی و شدید کلیک در حالی که جایگاه‌ها تغییر نکرده‌اند، الگوی مشخصِ ایستادن یک صفحه‌ی هشدار بین کاربر و سایت شماست — نه افت رتبه. این دو تشخیص، دو درمان کاملاً متفاوت دارند.
دسته‌بندی هشدارهای امنیتی و معنای دقیق هرکدام
گزارش Security Issues مشکل را در یکی از چند دسته قرار می‌دهد. شناختن دسته مهم است، چون مسیر رفع هر دسته متفاوت است.
| دسته | یعنی چه | معمولاً کجا را باید نگاه کرد |
|---|---|---|
| بدافزار (Malware) | صفحه‌ای از سایت شما کدی اجرا یا توزیع میکند که به دستگاه بازدیدکننده آسیب می‌زند یا داده‌اش را می‌دزدد | اسکریپت تزریق‌شده در قالب و صفحات، فایل‌های PHP آلوده، iframe مخفی، کد در جدول گزینه‌های پایگاه‌داده |
| محتوای فریب‌دهنده / مهندسی اجتماعی | صفحاتی که کاربر را فریب می‌دهند تا اطلاعات وارد کند یا نرم‌افزار نصب کند — از فیشینگ تا دکمه‌ی دانلود گمراه‌کننده | صفحات فیشینگ آپلودشده در پوشه‌های فرعی، تبلیغات و اسکریپت‌های تبلیغاتی شخص ثالث، فرم‌های جعلی ورود |
| دانلودهای مخرب (Harmful downloads) | فایل‌های قابل دانلود از سایت شما بدافزار تشخیص داده شده‌اند | فایل‌های آپلودشده توسط کاربران، آرشیوهای قابل دانلود، فایل‌های نصب‌کننده |
| دانلودهای غیرمعمول (Uncommon downloads) | فایل‌های شما به‌اندازه‌ی کافی شناخته‌شده نیستند تا Safe Browsing به آن‌ها اعتماد کند — این حتماً به معنای آلودگی نیست | نصب‌کننده‌های بدون امضای کد، فایل‌های اجرایی جدید یا کم‌دانلود |
| محتوای هک‌شده / تزریق محتوا | محتوای اسپم یا صفحات تولیدشده توسط مهاجم روی دامنه‌ی شما ایندکس شده است | صفحات و نوشته‌های تزریقی در پایگاه‌داده، قواعد بازنویسی در .htaccess، اسکریپت تولید صفحه |
دستهی آخر دقیقاً همان چیزی است که در فارسی به آن «سایت چینی شده» یا «سایت ژاپنی شده» می‌گویند. توجه کنید که «دانلود غیرمعمول» تنها دسته‌ای است که ممکن است هیچ آلودگی‌ای در پس آن نباشد — اگر شما نرم‌افزار توزیع می‌کنید، امضای کد و افزایش اعتبار فایل راهکار آن است، نه پاکسازی.
خواندن گزارش Security Issues در Search Console
مسیر: Search Console › Security & Manual Actions › Security issues. این گزارش سه چیز به شما می‌دهد و هر سه را باید استخراج کنید:
- دستهی مشکل. همان جدول بالا. اگر چند دسته هم‌زمان فهرست شده‌اند، معمولاً یعنی مهاجم چند نوع محتوا قرار داده است و پاکسازی باید هر دو را پوشش دهد.
- نمونه‌ی URLهای متأثر. این فهرست نمونه است، نه کامل. بزرگ‌ترین اشتباه رایج این است که تیم فقط همین چند URL را پاک میکند و درخواست بازبینی می‌دهد. گوگل نمونه می‌دهد تا الگو را بفهمید، نه تا فهرست کارتان باشد.
- توضیح و نمونه‌ی محتوای مخرب در بعضی دسته‌ها، که به تشخیص محل تزریق کمک میکند.
ابزارهای مکمل که واقعاً کمک می‌کنند
- URL Inspection: برای یک URL مشکوک ببینید گوگل چه چیزی دریافت کرده. تفاوت بین «چیزی که من می‌بینم» و «چیزی که خزنده می‌بیند» اصلی‌ترین سرنخ در حملات Cloaking است.
- گزارش Coverage/Pages: پرش ناگهانی تعداد صفحات ایندکس‌شده، ردپای تولید انبوه صفحه‌ی اسپم است.
- گزارش Performance: فهرست کوئری‌هایی که سایت شما برایشان نمایش می‌گیرد. کلیدواژه‌های نامربوط، تأیید مستقیم محتوای تزریقی است.
- Links report: در برخی حملات، مهاجم لینک‌های خروجی انبوه به سایت‌های خودش اضافه میکند.
بدون Search Console شما نه دستهی مشکل را می‌دانید، نه میتوانید درخواست بازبینی بدهید. تأیید مالکیت دامنه اولین کاری است که باید انجام دهید — و از آن به بعد، این ابزار سیستم هشدار زودهنگام شما برای دفعات بعد است. این موضوع بخشی از همان چیزی است که OWASP در دستهی A09:2025 (نقص ثبت رخداد و هشداردهی) به آن اشاره میکند.
چرا هشدار گرفته‌ام ولی خودم چیزی نمیبینم؟
این پرسش تقریباً در هر مورد واقعی مطرح میشود و پاسخش فنی و مشخص است: بدافزار مدرن شرطی عمل میکند. طراحی‌اش این است که مدیر سایت هیچ چیزی نبیند تا آلودگی طولانیتر دوام بیاورد.
- تشخیص کاربر لاگینشده: اگر کوکی نشست مدیر وجود داشته باشد، کد مخرب اجرا نمیشود.
- شرط روی
User-Agent: فعال شدن فقط برای موبایل، یا فقط برای خزنده‌ها، یا فقط برای مرورگرهای دسکتاپ. - شرط روی
Referer: فعال شدن فقط وقتی بازدیدکننده از نتایج جست‌وجو آمده باشد. - یک‌بار برای هر IP: با کوکی یا کش، هر بازدیدکننده فقط یک بار محتوای مخرب را می‌بیند. همین باعث میشود بازآزمایی شما موفق به نظر برسد.
- شرط جغرافیایی یا زمانی: فعال شدن فقط برای بازدیدکنندگان مناطق خاص یا در ساعات مشخص.
- محتوای مخرب در مسیرهای فرعی: صفحه‌ی فیشینگ در یک پوشه‌ی چندلایه که هیچ لینکی از سایت اصلی به آن نمی‌رسد.
روش درست آزمایش: از حالت ناشناس مرورگر، با عاملِ کاربری موبایل، با ارجاعدهندهی گوگل، و با ابزار URL Inspection. اگر همه‌ی این‌ها سالم بود و هشدار پابرجاست، احتمالاً محتوای مخرب در مسیری است که در نمونه‌ی URLها نیامده — از فهرست کامل فایل‌ها و از گزارش صفحات ایندکس‌شده شروع کنید.
«سایتم را باز کردم، سالم بود؛ حتماً گوگل اشتباه کرده.» ادعای مثبت‌کاذب باید آخرین فرض شما باشد، نه اولین. Safe Browsing بر پایه‌ی مشاهده‌ی رفتار واقعی صفحه کار میکند. اگر با درخواست بازبینی سعی کنید هشدار را بی‌آنکه چیزی را رفع کرده باشید بردارید، نتیجه فقط از دست دادن زمان است.
فرایند درخواست بازبینی، مرحله به مرحله
درخواست بازبینی (Request Review) سازوکاری است که با آن به گوگل اعلام می‌کنید مشکل رفع شده و از او می‌خواهید سایت را دوباره ارزیابی کند. ترتیب درست:
- پاکسازی را کامل کنید. نه فقط URLهای نمونه — همه‌ی محتوای مخرب، همه‌ی درهای پشتی، و همه‌ی سازوکارهای بازتولید (کران‌جاب، افزونه‌ی آلوده، کاربر مدیر مهاجم). فرایند کامل در پاکسازی سایت هک شده.
- نقطهی ورود را ببندید. اگر آسیب‌پذیری وصله نشده باشد، احتمال بازگشت آلودگی در فاصله‌ی بین ارسال درخواست و انجام بازبینی جدی است — و نتیجه، ردشدن بازبینی خواهد بود.
- راستیآزمایی کنید با روش‌های بخش قبل: حالت ناشناس، عاملِ کاربری موبایل، ارجاعدهندهی گوگل، و URL Inspection روی چند نمونه.
- در Search Console درخواست بازبینی را ثبت کنید و در توضیحات، دقیق و کوتاه بنویسید: چه چیزی آلوده بود، چه کاری برای رفعش انجام دادید، نقطهی ورود چه بود و چطور بسته شد، و چه اقدام پیشگیرانه‌ای اضافه کرده‌اید. توضیح مبهم مثل «مشکل رفع شد» به کیفیت بازبینی کمک نمی‌کند.
- در دورهی بازبینی سایت را تغییر ندهید و مطمئن شوید صفحات متأثر برای خزنده قابل دسترسی‌اند. اگر آن مسیرها را با
robots.txtبسته باشید یا حذف کرده باشید، بازبینی نمی‌تواند تأیید کند که پاک شده‌اند.
درباره‌ی زمان
صادقانه: زمان قطعی و تضمینشدهای وجود ندارد. بازبینی بسته به دستهی مشکل، اینکه فرایند خودکار است یا نیازمند بررسی انسانی، و شرایط دامنه متفاوت است و در منابع رسمی هم بهصورت یک عدد ثابت اعلام نمیشود. آنچه در کنترل شماست کاهش تعداد دفعات بازبینی است: یک درخواستِ کامل و درست، از سه درخواستِ نیمه‌کاره سریع‌تر به نتیجه می‌رسد. هر ردشدن، چرخه را طولانیتر میکند.
چرا درخواست بازبینی رد میشود
الگوهای شکست تکراری و قابل پیش‌بینی‌اند:
| دلیل ردشدن | ریشه‌ی فنی | راهحل |
|---|---|---|
| بدافزار هنوز روی سایت است | فقط URLهای نمونه پاک شده‌اند، یا محتوای مخرب در مسیرهای دیگری هم بوده | مقایسه با منبع سالم یا بازسازی کامل، به‌جای پاکسازی موردی |
| آلودگی در فاصله‌ی بازبینی برگشته | نقطهی ورود وصله نشده یا درِ پشتی باقی مانده | تحلیل ریشه‌ای، وصله‌ی آسیب‌پذیری، چرخش کامل اعتبارنامه‌ها |
| محتوای مخرب فقط برای خزنده سرو میشود | Cloaking؛ شما نسخه‌ی سالم را می‌بینید و خزنده نسخه‌ی اسپم را | آزمایش با URL Inspection و با عاملِ کاربری خزنده |
| صفحات متأثر برای خزنده قابل دسترسی نیستند | مسیرها با robots.txt بسته شده یا ۴۰۴ می‌دهند | اجازه‌ی خزش بدهید تا پاک بودن قابل تأیید باشد |
| مشکل، محتوای شخص ثالث است | اسکریپت تبلیغاتی یا ویجت بیرونی محتوای مخرب تزریق میکند | حذف یا جایگزینی آن سرویس؛ این مورد پاکسازی سرور را حل نمی‌کند |
| دستهی مشکل اشتباه تشخیص داده شده | مثلاً «دانلود غیرمعمول» با پاکسازی بدافزار حل نمیشود | امضای کد و افزایش اعتبار فایل، به‌جای اسکن سرور |
یک مورد ویژه‌ی مهم: اگر سایت شما ظرفیت پذیرش محتوای کاربر دارد (انجمن، بخش نظرات، آپلود فایل)، ممکن است هیچ نفوذی رخ نداده باشد و محتوای مخرب را کاربران اضافه کرده باشند. در این حالت پاکسازی کافی نیست؛ باید کنترل ورودی و اعتبارسنجی آپلود را اصلاح کنید، وگرنه چرخه تکرار میشود.
بازیابی سئو پس از رفع هشدار
برداشته شدن هشدار، پایان بحران است اما پایان کار نیست. آسیب سئویی یک دورهی آلودگی چند جزء دارد و هر جزء درمان خودش را می‌خواهد:
- پاکسازی ایندکس از صفحات اسپم. صفحات تزریقی باید یا حذف شوند و پاسخ
410/404بدهند، یا اگر مسیر معنادارتری وجود دارد ریدایرکت شوند. حذف انبوه با ابزار Removals در Search Console موقتی است و جایگزین حذف واقعی نیست. - نقشه‌ی سایت را بازسازی و ارسال کنید تا خزنده فهرست درست صفحات را دریافت کند.
- لینک‌های خروجی تزریقی را حذف کنید. در بعضی حملات هزاران لینک به سایت‌های اسپم اضافه میشود؛ باقی ماندن آن‌ها یک مسئله‌ی کیفیت محتوا برای گوگل است، جدا از مسئله‌ی امنیتی.
- وضعیت هسته‌ای صفحات مهم را بازبینی کنید: عنوان، توضیحات، داده‌ی ساختاریافته و محتوای صفحات کلیدی. بعضی بدافزارها این‌ها را هم دستکاری می‌کنند.
- انتظار بازگشت تدریجی داشته باشید. بازگشت کامل ترافیک به روند خزش دوباره، بازارزیابی صفحات و بازسازی اعتماد کاربر بستگی دارد. هیچ عدد قابل تضمینی برای مدت آن وجود ندارد — به‌ویژه اگر آلودگی طولانی بوده است.
- سرعت و پایداری سایت را بررسی کنید. بدافزارهایی که منابع سرور را مصرف می‌کنند اثر بلندمدت روی زمان پاسخ و در نتیجه روی تجربه‌ی کاربر می‌گذارند.
هزینه‌ی واقعی این حادثه معمولاً هزینه‌ی پاکسازی نیست؛ هزینه‌ی ترافیک و فروش از دست رفته در دورهی هشدار است. به همین دلیل، سرمایه‌گذاری روی پیشگیری تقریباً همیشه ارزان‌تر از بازیابی است. فهرست عملی این اقدامات را در جلوگیری از هک شدن سایت و افزایش امنیت سایت آورده‌ایم.
پیشگیری: چطور دوباره به این وضعیت نرسیم
هشدار امنیتی گوگل یک پیامد است. علت، آسیب‌پذیری‌ای است که اجازه‌ی تزریق محتوا داد. پس پیشگیری هم در سطح علت انجام میشود:
- Search Console را برای همه‌ی نسخه‌های دامنه فعال و اعلان‌های ایمیلی‌اش را روشن کنید. این سریع‌ترین سیستم هشدار بیرونی رایگان است.
- پایش یکپارچگی فایل‌ها و هشدار بر ایجاد کاربر مدیر را راه‌اندازی کنید.
- انضباط به‌روزرسانی داشته باشید. بیشتر تزریق‌های محتوا از یک افزونه یا کتابخانه‌ی وصله‌نشده شروع می‌شوند — همان چیزی که OWASP آن را در A03:2025 نقص‌های زنجیره‌ی تأمین نرم‌افزار دسته‌بندی میکند. برای سایت‌های وردپرسی، امنیت وردپرس نقطهی شروع است.
- محتوای تولیدشده توسط کاربر را جدی بگیرید: اعتبارسنجی آپلود با فهرست سفید، غیرفعال کردن اجرای اسکریپت در پوشه‌ی آپلود، و بازبینی نظرات و پروفایل‌ها.
- لاگ داشته باشید و نگهش دارید. بدون لاگ، تحلیل ریشه‌ای در حادثه‌ی بعدی هم غیرممکن خواهد بود.
- دوره‌ای ارزیابی کنید. یک تست نفوذ وب همان آسیب‌پذیری‌هایی را پیدا میکند که مهاجمان خودکار هم دنبالشان هستند، با این تفاوت که گزارشش به شما می‌رسد نه به آن‌ها. بررسی امنیت سایت نسخه‌ی سبک‌تر همین کار است.
اگر همین حالا در وضعیت هشدار هستید و می‌خواهید چرخه‌ی «پاکسازی، ردشدن بازبینی، آلودگی دوباره» را قطع کنید، بازیابی سایت هک شده‌ی پی‌هانتر فرایند را از تحلیل ریشه‌ای شروع میکند، نه از حذف فایل. برای مشورت پیش از تصمیم هم مشاوره‌ی امنیتی در دسترس است.
پرسش‌های متداول
سایتم در گوگل بلاک شده، چطور رفعش کنم؟
سه مرحله به همین ترتیب: (۱) در Search Console دستهی مشکل را در بخش Security issues مشخص کنید، (۲) آلودگی را کامل پاکسازی و نقطهی ورود را وصله کنید، (۳) بعد از راستیآزمایی، درخواست بازبینی بدهید. اگر مرحلهی دوم ناقص باشد، مرحلهی سوم رد میشود.
درخواست بازبینی گوگل چند روز طول میکشد؟
عدد ثابتی وجود ندارد و منابع رسمی هم زمان تضمینشدهای اعلام نمیکنند؛ بسته به دستهی مشکل و اینکه بررسی خودکار است یا انسانی، متفاوت است. مهمترین کاری که میتوانید بکنید این است که درخواست را فقط یک بار و بهصورت کامل بدهید، چون هر ردشدن کل چرخه را طولانیتر میکند.
تفاوت جریمه امنیتی گوگل با جریمه سئو چیست؟
هشدار امنیتی از Safe Browsing میآید، در بخش «Security issues» گزارش میشود، دلیلش خطر برای کاربر است و با پاکسازی و درخواست بازبینی رفع میشود. جریمهی سئو (اقدام دستی) در بخش «Manual actions» است، به نقض دستورالعملهای محتوایی مربوط میشود و مسیر رفعش کاملاً جداست. اشتباه گرفتن این دو باعث میشود هفتهها روی راهحل نامربوط کار کنید.
بعد از رفع هشدار، ترافیکم کِی برمیگردد؟
برداشته شدن هشدار بلافاصله مانع فنی را حذف میکند، اما بازگشت کامل ترافیک به خزش دوبارهی صفحات، حذف صفحات اسپم از ایندکس و بازسازی اعتماد کاربر بستگی دارد. هیچ زمان قابل تضمینی وجود ندارد؛ هرچه دورهی آلودگی طولانیتر بوده، بازگشت تدریجیتر است.
چرا گوگل میگوید سایتم بدافزار دارد ولی من چیزی نمیبینم؟
چون بدافزار شرطی است: برای کاربر لاگینشده اجرا نمیشود، یا فقط برای موبایل، فقط برای ترافیک ورودی از گوگل، یا فقط یک بار برای هر IP فعال میشود. با حالت ناشناس، عاملِ کاربری موبایل، ارجاعدهندهی گوگل و ابزار URL Inspection آزمایش کنید — نه با باز کردن سایت در مرورگر همیشگی خودتان.
آیا میتوانم بدون پاکسازی، فقط درخواست بازبینی بدهم؟
میتوانید ثبت کنید، اما نتیجه ردشدن است و فقط زمان از دست میرود. بازبینی محتوای واقعی صفحات را ارزیابی میکند. ترتیب درست همیشه پاکسازی کامل، بستن نقطهی ورود، راستیآزمایی و بعد بازبینی است.
منابع
محمدرضا مقدم
مغز خودکارسازی تیم؛ ابزارها و زیرساخت داخلی پی‌هانتر را می‌سازد تا اسکن و گزارش‌گیری سریع‌تر و دقیق‌تر انجام شود.